Request for Proposal - Purdue University by wulinqing

VIEWS: 13 PAGES: 42

									                                            PURDUE UNIVERSITY
                                PURDUE UNIVERSITY STUDENT HEALTH CENTER
                                          REQUEST FOR PROPOSAL
                              FOR A MEDICAL MANAGEMENT SOFTWARE PACKAGE


                                                             TABLE OF CONTENTS



SECTION                                                                                                                                                 PAGE


SECTION I - INTRODUCTION AND BACKGROUND ............................................................................ 2
  Project Introduction........................................................................................................................................ 2
  Project Scope.................................................................................................................................................. 3
  Project Implementation .................................................................................................................................. 3
  Business Requirements .................................................................................................................................. 4
  Schedule of Events ......................................................................................................................................... 4
  Institutional Contacts ..................................................................................................................................... 4
  Content of Request for Proposal .................................................................................................................... 5
  Selection Criteria............................................................................................................................................ 5
  Additional Vendor Information ..................................................................................................................... 7
  Purdue University and Current Operations .................................................................................................... 7

SECTION II - PROPOSAL FORMAT ........................................................................................................ 10

SECTION III – INSTALLATION & SUPPORT SPECIFICATIONS .................................................... 15

SECTION IV – PUSH SYSTEM SPECIFICATIONS ............................................................................... 17

APPENDIX A - OPERATING ENVIRONMENT ...................................................................................... 24

APPENDIX B - NOTICE OF INTENT FORM .......................................................................................... 26

APPENDIX C - SECURITY QUESTIONS/SPECIFICATIONS .............................................................. 27

APPENDIX D - DATA FIELD REQUIREMENTS ................................................................................... 29

APPENDIX E - PROJECT CHARTER ...................................................................................................... 30

APPENDIX F - PURDUE UNIVERSITY PROFESSIONAL SERVICES AGREEMENT ................... 36
                                             Section I: Introduction and Background

                                          Section I
                         INTRODUCTION AND BACKGROUND

Purdue University requires that all information in the RFP be held confidential by the vendor.

Project Introduction
The Purdue University Student Health Center (PUSH) in conjunction with several departments
across campus accepted a major undertaking to search and procure a new medical management
software package to replace the Dataflow system currently in use. It has been the mission of the
Student Health Technological Advancement Endeavor team to define existing processes,
research vendors and prepare the PUSH staff for a transition to a medical management software
package that will enhance service to the Health Center clientele and respond to innovative
changes in technology. To successfully accommodate user needs the new system must be in
place by February 2002.

Primary Users Include
 Providers, Nurse Practitioners, administrators, and other staff at multiple PUSH locations,
   but residing on the same sub-net. Access will be via the Purdue Data Network (PDN).
 Patients will access system from the web site for appointments.
 User interfaces with the Centralized Accounts Receivable system (CARS) and student
   information systems within the Office of the Registrar (SITP).

Project Objective
1. Will give the staff and providers a better tool to care for the student population and more
    quickly respond to their health needs.
2. Can be more easily updated to reflect the needs of PUSH.
3. Allows PUSH to position itself to take advantage of new electronic imaging, automation,
    and web technology.
4. Generates accurate reports and statistics to help PUSH better determine future direction
    and need.
5. Increases efficiency, accuracy and flexibility with state-of-the-art medical management
    software designed for outpatient clinics. At a minimum, the software will
     Track patient’s medical visits.
     Schedule appointments.
     Print labels, patient statements, encounter forms, receipts, etc.
     Provide statistical and financial reports.
     Interface with University departments.
     Handle electronic medical records and allow for electronic billing.
     Support ancillary services.
     Provide a user-friendly, Windows-based graphical user interface.
     Support Web-based features.


Student Health Technological Advancement Endeavor           Revised: 12/3/2011                   2
                                              Section I: Introduction and Background

6.   Generates more reliable data and smoothly transfer this data to and from CARS and SITP.
7.   Meets the needs of PUSH so that costly and time-consuming modifications can be
     avoided.
8.   Establishes a partnership with a vendor who readily supports its software and responds to
     the needs and requests of their clients. A vendor that will remain its own entity and retain
     control of its own future and software packages.

Project Scope
Several University departments are involved with this project, each for a particular reason.
1. The Purdue University Student Health Center will be the department to receive this
    software. It will be PUSH that will ultimately learn to use this software and be on the
    frontline to maintain the data stored in the system.
2. Student Services Computing Zone is affected in that it supports the desktops used in the
    building. They will be responsible to maintain those desktops that are the links to the
    medical management software. Currently, all workstations housed at PUSH meet vendor
    specifications to run their software.
3. Management Information will be involved in that they will house and maintain the
    servers, be it Unix- or NT-based, on which the medical management software and data
    resides. In addition to this during the vendor demonstrations, individuals representing
    certain areas at MI (NT, Unix, Security, DBA, Applications) will be invited to help
    evaluate vendor software products.
4. Internal Audit will be scrutinizing the software choices to determine whether the
    packages are compliant to University standards in the areas of audit trails and security.
5. The office responsible for the Centralized Accounts Receivable system must be involved
    to help determine the reliability of the system to transfer charges and payment information
    to and from CARS and PUSH. Three options in this area exist:
     PUSH transfers all charges and payments to CARS to be handled by the University.
     PUSH retains all charges and payments and will age accounts internally.
     PUSH ages account internally for a specified time, then transfers to CARS.
6. The Office of the Registrar will be on the committee as they are involved with the
    transfer of student demographics, encumbrance information and immunization records.
7. Purchasing will help in securing an agreeable contract with the vendor selected.

Project Implementation
PUSH Staff, the selected vendor, Student Services Computing, the Office of the Registrar, the
offices (UCO) responsible for the Centralized Accounts Receivable system and Management
Information will be responsible for installation of the system and required interfaces, as well as
migration of existing student data, hardware installation, administrative codes, insurance
information, etc. to the new system. It is hoped that the vendor will be able to provide a
programmable interface between their software and Dataflow for the transfer of information. If
this cannot be done with the greatest of authenticity it is expected that the PUSH Staff would
assume the responsibility for the data entry into the new system.


Student Health Technological Advancement Endeavor            Revised: 12/3/2011                 3
                                              Section I: Introduction and Background

Business Requirements
The successful system will include the following features within its software:
 Storing and tracking patient records;
 Controlling patient check-in, check-out and appointments;
 Requisitioning of lab work and x-rays;
 Managing accounts receivable and billing;
 Electronic insurance billing via a clearinghouse;
 Gathering statistics and reporting of such data;
 Interface with University departments;
 Growth opportunities with an electronic medical record and web based technologies;
 Long term company profile and directional growth;
 Training methodology for conversion and installation;
 Ability to support and be driven by user groups.

Schedule of Events
Description                      Completed by:
Internal Review – RFP            June 22, 2001
RFP Release Date                 June 29, 2001
Notice of Intent Due Date        July 6, 2001 (see Appendix B for reply form)
Proposal Due Date:               August 6, 2001 12:00 noon E.S.T. (see Section II for
                                 format/guidelines. NOTE: Late proposals will not be accepted.)
Vendor Demonstrations            August 20, 2001 – September 7, 2001
Notice of Award                  Not later than September 28, 2001
Contract Execution               Not later than October 12, 2001
Implementation of Software       Will vary by vendor recommendation, however, no later than
                                 February 2002.

Institutional Contacts
The primary contact person for RFP procedural questions is Eric E. Fulkerson, Purchasing
Department, 401 South Grant Street, 1067 Freehafer Hall, West Lafayette, IN 47907. His
telephone number is 765.494.9693 and his fax number is 765.494.6609. If there are changes,
additions or clarifications to the RFP after it is released, an addendum will be issued and sent to
all vendors.

Project Managers
 D. Jim Layman, Business Manager, Departmental Coordinator & Co-Project Manager
 Janet Moore, Co-Project Manager
 Greg Sabens, Systems Administrator & Co-Project Manager




Student Health Technological Advancement Endeavor            Revised: 12/3/2011                  4
                                              Section I: Introduction and Background

Content of Request for Proposal
There is a one page Table of Contents. The main body of the RFP is numbered consecutively
on pages 2 – 22. Appendix A is on pages 23 - 24. Appendix B is on page 25. Appendix C is on
page 26 - 27. Appendix D is on page 28. Appendix E is on page 29 - 34. If your copy of this
document is missing any pages, please notify the primary contact person, Eric E. Fulkerson.

Selection Criteria
The award of a contract will be based upon the following criteria:
 Functionality – Prospective software supports the business function as well or better than
    our existing system. Prospective software supports business needs as defined in the process
    mapping, is flexible and has growth potential in areas we have defined. Product is easy to
    use and administer.
 Costs – Product and Support costs are well apportioned and manageable in a state supported
    institution.
 Implementation costs are proportional to the value received. The total cost of ownership,
    from implementation to continuing support, is very reasonable.
 Service/Support – Support is available, reasonably priced and of highest quality. Service
    staff is well trained and stable. Company understands the higher education calendars
    demand 24 hour/7 day operations.
 Technology – Company is at the cutting edge of the newer technologies for student health
    data systems. At the same time, systems are stable and user-friendly. Company shares its
    technology and training capabilities freely with the customer.
 Vision – Company goals for product will make it develop ahead of or concurrently with
    customer needs.
 Company respects the vision of the customer institution and supports the institution’s
    strategic efforts to excel.
 Ability to Execute – Company is committed to the higher education community and
    understands the environment and its limitations. Track record shows successful efforts in a
    similar environment. Company does not expect customer to train its staff or to develop the
    product, which it can then sell. Company is willing to put its reputation on the line for
    institution’s installation.
 Implementation – Company is able to work hand-in-hand with PUSH to ensure a successful
    conversion, training and installation of its product.
 Stability – Long-term prospects and outlook for the company are stable and growth
    orientated.

Purdue University reserves the right to award by item, group of items, or total proposal. Purdue
University further reserves the right to reject any or all bids and to waive any of the terms,
conditions and provisions contained in this Request for Proposal if it is determined that the best
interest of Purdue University will be served by so doing. In determining an award,
qualifications of the prospective vendor, conformity with specification of goods and/or


Student Health Technological Advancement Endeavor            Revised: 12/3/2011                 5
                                           Section I: Introduction and Background

services, cost, and delivery of terms will be considered by Purdue University in absolute and
sole discretion.




Student Health Technological Advancement Endeavor         Revised: 12/3/2011               6
                                              Section I: Introduction and Background

                         ADDITIONAL VENDOR INFORMATION

Notice of Intent to Respond
Please return the attached reply form (in Appendix B) by July 6, 2001 indicating whether or
not you intend to participate. If you intend to participate, please indicate on this form the
person who will serve as the focal point for contact throughout the RFP process for your
organization.

Demonstration of Proposed System
Vendors will be required to make a ‘live’ demonstration of their working system. Additionally,
as part of the demonstration, Purdue University may ask the vendor to participate in a
‘structured’ demonstration using a script provided by the Project Manager. In addition, Purdue
University staff will ‘test’ by simulating practical situations. This demonstration will be at the
West Lafayette campus of Purdue University scheduled by the Project Manager. A vendor
technical representative must be in attendance during the simulation to answer any
technical questions Purdue University staff may have. Purdue University shall not be
responsible for any vendor costs associated with the demonstrations and any such costs shall be
the full responsibility of the vendor.

The product demonstrations are considered to be a critical step of the overall evaluation and are
intended as the primary vehicle by which Purdue University is to become familiar with each
vendor’s capabilities. The purpose of such demonstrations will be to substantiate and clarify
statements made in the written responses within the vendors' proposals. It is possible that
issues and/or additional requirements will be identified during the demonstration that will
require additional information or clarification. If this occurs, the vendor(s) will be given
sufficient time to provide such information or clarification in writing.

                              ABOUT PURDUE UNIVERSITY

History
Founded in 1869, Purdue is the state of Indiana’s land-grant university. As one of the 25
largest universities in the United States, Purdue is a leading research institution with a
reputation for excellent and affordable education, a member of the Big Ten Conference, and is
the home of the Purdue Boilermakers athletic teams.

Purdue is a statewide university with students at the main campus in West Lafayette and at
three regional campuses. In addition, Purdue extends its boundaries to numerous teaching and
research sites throughout Indiana and the world. Traditionally, as a land-grant university,
Purdue’s strongest programs have been in engineering and agriculture. Purdue now offers
more than 200 programs of study in schools of Agriculture, Consumer and Family Sciences,
Education, Engineering, Health Sciences, Liberal Arts, Management, Nursing, Pharmacy and
Pharmacal Sciences, Technology and Veterinary Medicine.


Student Health Technological Advancement Endeavor            Revised: 12/3/2011                 7
                                              Section I: Introduction and Background

Students
Total student enrollment exceeded 66,500 in the fall of 2000, of which about 38,000 are
enrolled at the West Lafayette campus.

Faculty and Staff
Purdue University is the second largest employer in the State of Indiana. The number of
faculty and staff University-wide exceeds 14,500 with over 80% located at the West Lafayette
campus. Approximate employment by staff type includes 3,600 faculty; 2,900 administrative
and professional, 1,800 clerical, 2,300 service and 3,300 graduate assistants.

Financial and Accounting practices
Purdue’s fiscal year is July 1 to June 30, and the principles and practices of fund accounting are
employed. Fund accounting permits the University to segregate revenues and expenditures into
separate funds by source and/or purpose. Collectively, Purdue’s total assets as of June 30, 1999
were reported at over $2 billion. The University’s creditworthiness is evaluated regularly by
both Standard and Poor’s and Moody’s, and has received high AA and AA2 ratings
respectively by these firms.

Purdue University Campus Locations
Purdue Calumet is located in Hammond, in Lake County southeast of Chicago. With the
completion of the new Classroom Office Building, the campus has twelve primary buildings.
Purdue North Central is located in Westville, in LaPorte County east of the Calumet Region.
North Central is the smallest of the regional campuses with six main buildings.
Indiana University-Purdue University Ft. Wayne is a joint facility with the state’s other large
university. Administered by Purdue, it is located in Fort Wayne, in Allen County in the
northeastern portion of the state. It is the largest of the Purdue regional campuses with nineteen
major buildings.

West Lafayette Campus
The main campus at West Lafayette, in Tippecanoe County an hour northwest of Indianapolis
and 125 miles southeast of Chicago, is a large, residential campus with extensive residence,
athletic and research facilities.

Purdue University Student Health Center
The Student Health center employs 98 full-time employees. Twelve of these employees are
fulltime Physicians and three more are part time in Urgent Care. There are five fulltime and
one part time Nurse Practitioners. The Student Health center also employs more than 15
nurses, four Medical Assts and 6 Psychologists. Administrative and Clerical staff total 37 with
15 employees in Service. Last fiscal year, the Student Health center’s Physicians and Ancillary
services provided for 60,000 visits




Student Health Technological Advancement Endeavor            Revised: 12/3/2011                 8
                                          Section I: Introduction and Background

                               CURRENT OPERATIONS

The hardware/software environment consists of approximately 80 PCs, Pentium III 450s or
higher, running Windows 95 (soon to be migrated to Windows 2000 Professional). We are
connected to a Novell Netware 5 network and a Windows NT Domain with direct access to the
Internet. The Dataflow software system has been in use since 1994. With Dataflow, PUSH
tracks patient’s medical visits, diagnoses and procedures, charges incurred and billing.

PUSH interfaces with other University departments, thus data is transmitted to and from the
Registrar’s department, which provides student demographics, encumbrance information and
immunization records. Data is currently shared between CARS and PUSH. These are required
processes.

The Student Health Center of Purdue University houses several of its own ancillary services
(i.e. – Laboratory, Allergy and Immunizations Clinic, Physical Therapy and Radiology).




Student Health Technological Advancement Endeavor       Revised: 12/3/2011               9
                                                             Section II – Proposal Format

                                           Section II
                                    PROPOSAL FORMAT

Format and Organization
To ensure the equitable evaluation of the submitted proposals, Purdue University requires that
the responding vendors organize their proposals into the following categories of information:
1. Corporate Information
2. Costs/Contract/Licensing Agreement
3. Financial Information
4. Compliance with Purdue University Architecture Standards
5. References/User Group
6. RFP Responses
7. Appendices

Six (6) original sets of the proposal must be submitted in a loose-leaf format in a three- (3) ring
binder divided into the categories outlined above. Facsimile copies will not be accepted.
Proposals received after the due date will not be accepted.

Listed below are the specific requirements as to the contents of each of these categories.

Response Format
Repeat the question prior to providing your narrative. Please note the following:
1. Each requirement question must be answered descriptively, avoiding a simple “yes/no”
    answer whenever possible.
2. All requirement questions must be accounted for within your narrative response.
    Completeness and thoroughness of the narrative response is expected.
3. Use the following codes when responding to Section 6 - RFP Responses. Indicate at the
    end of each response the appropriate vendor code/description from the list below:
     Code 1 - Functionality is provided with no need to change or purchase additional
         components of the delivered base system. Only proper training and table content
         understanding is required.
     Code 2 - Functionality is provided by using provided “tools” to tailor the system.
         Tool utilization is intended to be used by end users or PUSH staff, not a technical
         person (by training).
     Code 3 - Functionality is provided by the utilization or purchase of an additional
         functional capability (module) from our product set, at an additional cost.
     Code 4 - Functionality is provided by MINIMAL code modification requiring
         technical expertise in package software.
     Code 5 - Functionality is provided by SIGNIFICANT time, investment in modifying
         package software by staff (internal Purdue University, or vendor provided) familiar
         with the package.


Student Health Technological Advancement Endeavor            Revised: 12/3/2011                10
                                                           Section II – Proposal Format

        Code 6 - Functionality will be provided in the future, by an already identified
         enhancement/release.
        Code 7 - Functionality cannot be provided beyond the scope of our systems
         capability.
        Code 8 - Functionality is provided by the utilization or purchase of an additional
         functional capability (module) from a THIRD PARTY, AT ADDITIONAL COST.
         Where possible, provide an estimate of the cost of implementing this level of
         functionality.

All proposals must conform to the Proposal Outline presented above. Any additional
background material, brochures, product sheets and other sales tools, etc. should be included as
Appendices, and submitted separately. Purdue University expects specific deliverables within
the vendor proposal. For each category, they are as follows:

Category 1 - Corporate Information (Submit the following):
Background and Basic Information
1. Entity legal name.
2. Address and telephone number.
3. Key contact name and title.
4. Type of entity (e.g. partnership, corporation, etc.).
5. Fiscal year period.
6. Length of time the firm has been in business (privately and publicly).
7. Pertinent information about key stockholders, if applicable (name, title, ownership interest,
    and background).
8. Pertinent information about key management employees (name, title, years with
    company).
9. Current members of the board of directors (name, dates of service).
10. Current members of the audit committee (name, dates of service).
11. If applicable, state whether or not you are a minority, small, or women owned business.

General Business Information
1. Affiliated organizations or related parties (name of related party, nature of relationship).
2. The number of current full-time equivalent employees (FTE) and FTE for each of the past
   eight quarters.
3. List the percentage of consulting/software work that is outsourced or subcontracted and
   with whom.
4. List your top three customers and the percentage of total annual income from each of these
   customers.
5. List your top three vendors and the percentage total annual expense paid to each.
6. Describe significant trends within the industry (e.g. growing, stable or declining).
7. Describe how growth and financial results compare with those of the industry and the
   reasons for significant variances.


Student Health Technological Advancement Endeavor           Revised: 12/3/2011                11
                                                            Section II – Proposal Format

8.    Comment on any unusual labor problems or shortages.
9.    Comment on competition, including significant shifts in market share.
10.   Describe nature of significant assets, liabilities, revenues, and expenses.
11.   Describe the extent of government regulations that may have a material effect on your
      operation.

Category 2 - Costs/Contracts (Submit the following):
1. A detailed response to all items relating to the cost of the products and services that you
    are proposing to Purdue University including potential modification work and add-on
    modules.
2. A copy of your standard licensing agreement for the products and services you are
    proposing to Purdue University.
3. A copy of your standard maintenance contract (if separate from the licensing agreement).
4. Any third party costs or maintenance agreements.
5. Any applicable published price list(s) as appropriate.
6. List your past and anticipated software release schedule.

Category 3 - Financial and Related Information (Submit the following):
Financial Information:
Independent Auditor's Opinion of Financial Statements for prior three years.
1. Income Statements for prior three years and for each quarter of the current year.
    Statements provided should minimally include:
     Sales
     Interest Income
     Cost of Goods Sold
     Interest Expense
     Depreciation and Amortization
2. Balance Sheets for prior three years and for each quarter of the current year. Statements
    provided should minimally include:
     Cash
     Accounts Receivable
     Inventory
     Other Current Assets
     Accounts Payable
     Short Term Debt Payable
     Other Current Liabilities
     Notes Payable
     Long Term Debt
3. Footnotes presented with Financial Statements for prior three years.
4. Copies of issues from management letters or other information received from your
    independent accountant.


Student Health Technological Advancement Endeavor           Revised: 12/3/2011                12
                                                             Section II – Proposal Format

5.   Bond ratings and stock prices for past three years and each quarter of the current year, if
     applicable.

Banking Relationships and Funding Sources:
1. Primary commercial banking partners, and bank balances for each of the past 12 months,
   including lines of credit, checking accounts, investments, debt, etc.
2. Confirmation that the banks have been authorized to share information with us regarding
   the bank's assessment of viability.
3. For each banking partner, provide name, address, telephone number and contact person.
4. List of top three venture capitalists or funding sources.

Legal Information:
1. Legal firm's name, address, telephone number and contact person.
2. Confirmation that the legal firm has been authorized to share information with us
    pertaining to pending litigation or legal issues.
3. Information on any pending litigation or legal issues that could materially affect the
    operation.
4. Information on any extraordinary contractual obligations requiring payment over the next
    three years.
5. Information on any mergers, acquisitions, or dispositions that are planned or likely.
6. Copy of Form 9, Request for Taxpayer Identification Number and Certification.

Category 4 - Compliance with Purdue University Architecture Standards
Explain how your system complies with Purdue University Architecture Standards defined in
Appendix A of this RFP.

Category 5 - References/User Group
Include the name, address and phone number of at least five (5) client companies and the
primary contact involved in their implementation of the system you are proposing. Vendors
should verify with these companies that they consent to be contacted by Purdue in regard to this
RFP. These clients are to be utilizing your system and all of these clients must be higher
education institutions.

Please list whether consulting services were provided to the client to improve the business
process. If consulting services were provided, were they done by your company or a third party
vendor?

Additionally, for each client reference, vendors are asked to indicate the years in which the
client purchased the product, if the product(s) is identical to the one(s) being proposed, or, if
different, how it is different, and if the product is in production mode?




Student Health Technological Advancement Endeavor            Revised: 12/3/2011                13
                                                           Section II – Proposal Format

If there is a formal User Group established for the specific product or system being proposed,
provide in this category of your proposal the name, address, phone number, and e-mail address
of the User Group Chairperson(s).

Category 6 - RFP Responses
This category must contain responses to the evaluation scenarios/questions presented in Section
III (Installation and Support Specifications), Section IV (User System Specifications) and
Appendix C (Security Questions/Specifications) of this RFP.

Category 7 - Appendices
Appendices must be submitted in a separate three (3) ring binder. Include any supportive
materials you deem necessary to supplement your answers. Such items as Standard Reports,
Training Course Material, appropriate marketing material, reprints of articles, internal
publications, etc. should be submitted here.

Note: Only one copy of each appendix needs to be submitted with your proposal.




Student Health Technological Advancement Endeavor          Revised: 12/3/2011              14
                                  Section III – Installation & Support Specifications

                                          Section III
                    INSTALLATION & SUPPORT SPECIFICATIONS

1.   Conversion Support
     A. Describe what support, if any, you provide for conversion and implementation. The
        current data uses Dataflow/Mends software.
     B. List the utilities available to convert historical data, table information, and existing
        Dataflow/Mends master files to the new system's master files and tables.
     C. What is your process to insure correctly converted data?
     D. List any other relevant vendor(s)' products for which you provide direct conversions.

2.   Release Support
     A. Explain the procedure for your issuing a general release and its impact on our
         previously made customization/modifications.
     B. How often in the last two years have you issued a "major high-level" release or
         upgrade? Please explain your notification and transmittal process in detail.
     C. What type of documentation is typically provided with a new release?
     D. When a new release is available, how many previous releases remain supported, and
         for how long?

3.   Installation Support
     A. Summarize the roles of the vendor and client in the installation process. What on-site
         and off-site project management support do you provide? What support is included in
         the software purchase price?
     B. How soon after contract signing can an installation be scheduled?
     C. What is your recommendation for initial training prior to installation (if any)?
     D. Are standard test files available with which to execute the acceptance test?
     E. How many people were on the installation team on the previous three installations for
         higher education institutions? Please differentiate between installation team members
         from the institution and installation team members’ external to the institution.

4.   Operational Redesign
     A. Summarize how you evaluate the efficiency of the current business process.
     B. Explain how responsibilities and roles have been redefined for prior office staff
        members at other sites.
     C. Does your company or a third party vendor provide consulting services?

5.   Implementation Support
     A. What support do you provide in support of your clients in overall implementation
         planning, project management, etc.?
     B. Is this support from your employees or do you recommend third party
         consultants/specialists familiar with your software?

Student Health Technological Advancement Endeavor            Revised: 12/3/2011               15
                                 Section III – Installation & Support Specifications

     C.   Provide an implementation plan for your software on Purdue University provided
          hardware platform. This plan should include migration of data from the legacy
          system.

6.   Maintenance Support
     A. Give a description of your support facilities stating what functions are provided with
        the standard agreement and what optional support is available at additional cost.
     B. Explain how support calls are prioritized and under what circumstances and how
        quickly on-site support can be provided.
     C. Is there a facility for a client to transmit a program dump to the office supporting the
        account?
     D. Is there the potential for you to dial into our system for purposes of problem
        resolution? If so, should Purdue University require this service?
     E. Do you have a technical support service? Describe how it operates (hours and days of
        operation, toll-free telephone number, etc.). Are the employees staffing the technical
        support assigned full-time to that function?
     F. Is there a "Bulletin Board" to relay program bugs to other clients? How do you notify
        other clients of bugs identified by a client?

7.   Hardware and Software Requirements
     A. What is the optimal hardware specification required to run the proposed system?
        (Include processors, memory, and hard disk requirements).
     B. What is the required operating system?

8.   Training
     A. Describe the training provided with the purchase of your software product(s) for both
         users and data processing personnel, giving the time limit, if any, on the use of the
         training provided. State the number of days and type of training available.
     B. What additional training, on-site or off-site, is available? At what cost?
     C. Do you provide "consulting services"? How do these differ from the support services
         included in the software purchase? Provide a schedule of fees and a list of the types
         of tasks for which you might provide consulting services.
     D. Is there now the ability to provide your clients a tutorial? Possibly on CD-ROM?
     E. Provide a current course curriculum showing related costs in the Appendix.

9.   User Group
     A. Describe the relationship between the User Group and your organization.
     B. How often does the User Group meet? Is there a national meeting?
     C. Explain if, or how, the User Group influences the priority of system modifications
         and enhancements?




Student Health Technological Advancement Endeavor           Revised: 12/3/2011               16
                                             Section IV – PUSH System Specifications

                                          Section IV
                            PUSH SYSTEM SPECIFICATIONS

1.   Administration
     A. Please describe the file and directory structure of your software including defining the
        tables and how each is used in the software.
     B. How can your data be directly accessed via Microsoft product such as Word and/or
        Excel?
     C. Can the system be setup to recognize 'filters' (flags, conditions) to determine whether
        a patient is eligible to receive services?
     D. Does your system enable creation of customized work environments and configurable
        screens?
     E. Will we be able to customize the data tables so that we will be able to distinguish
        between full-fee, non-fee and staff? Will these customized data fields be reportable?
     F. Will the system time and date stamp with the users login ID any and all modification
        to any data within the system?
     G. Can security levels be set such that user may be able to view data on a screen, but not
        modify it? Can this be set at the field level? Can certain screens or fields be invisible
        to some users while other users have full access?
     H. When we receive payment files from CARS, we want the system to confirm existence
        of a patient’s account before applying the payment. In the same way, if changes to
        the student’s demographics occur, before they are applied we would like for the
        system to determine if that student currently exists in the system or is a new student
        for the system. Can your software provide this for us?
     I. What options does the vendor recommend to move data from our existing system to
        the new system? Does the vendor provide this service?
     J. Can the system make a distinction between athletes and non-athletes?

2.   Allergy and Immunization Clinic
     A. Being a college campus, we must comply with state/federal laws and encumber
         students that do not have current immunizations and vaccinations. How can your
         system help us determine these students?
     B. Does the system allow for differing immunization requirements by matriculation
         date?
     C. Does compliance logic track recommended interval for series of doses to determine
         immunity by vaccination.
     D. We must occasionally notify the Office of the Registrar of students who do not have
         the required immunizations. Patients that have birth date, religious or medical
         exemptions should not show up on that report. How can your system provide for
         these exemptions?




Student Health Technological Advancement Endeavor           Revised: 12/3/2011                17
                                            Section IV – PUSH System Specifications

3.   Appointments
     A. Describe the appointments/scheduling portion of the software.
     B. If two users try to enter an appointment for the same day, time and provider, will the
        system notify these users that a double-booking situation is occurring at that moment?
     C. Can the system verify, as soon as the patient's name is typed in, whether that patient
        can be seen or not according to the fee status of that patient?
     D. Can chart requests and rosters be printed without closing down the appointments
        screens?
     E. If there are certain codes used within the appointments module to determine different
        types of visits, are those hard-coded into the system or definable by the customer?
     F. Can different appointment scheduling calendars be setup for different clinics and
        providers apart from each other?
     G. Is your system capable of allowing patient to setup appointments online through the
        Web?
     H. Does the system use a color-coding scheme for different types of entries in the
        appointments screen?
     I. What fields are available to search on?
     J. Can providers be double-booked? Will the user be notified of a double-booking
        situation?
     K. What is the length of times for appointments (5, 10, 15, 20, 30 minutes)? Can they be
        intermixed?

4.   Business Office
     A. The system must have the ability to charge one co-pay/day/insurance company. Is
         this possible with your system?
     B. Is it possible to lock out the billing screen so that users can post payments but not
         make adjustments?
     C. Does the company supply or host a clearinghouse for electronic claims?
     D. Can the software manage a cash drawer?
     E. Can the system automate fee schedules based on the patient's eligibility status and
         whether they have health insurance provided by the University or if they have
         commercial insurance coverage?
     F. Can HCFA 1500s be generated in batch and also on demand? Can they be tailored so
         that correct information is printed based on the type of insurance that the individual
         has (i.e. - Medicare may have one set of requirements in comparison to a commercial
         third party insurance).

5.   Compliance Information
     A. Is the company aware of and considering the ramifications of HIPAA? Will HIPAA
        compliance be reflected in the software
     B. Is the company/software currently HIPAA compliant?



Student Health Technological Advancement Endeavor          Revised: 12/3/2011                18
                                            Section IV – PUSH System Specifications

     C. As HIPAA statutes are required by law, will the company stay informed of these
        changes and will updates be made to the software? Will these HIPAA updates be
        included with the updates covered by annual licensure fees or be separate?
     D. Has the company programmed the software in such a way to recognize State and
        Federal immunization requirements?

6.   Procedure and Diagnosis Codes
     A. Will there be cross-referencing between CPT and ICD-9 (i.e. – male patient cannot
         get a pregnancy test)?
     B. In what ways does your company provide or support the updating of CPT and ICD-9
         codes for the system?

7.   Electronic Medical Records
     A. Does your software contain an Electronic Medical Records (EMR) package? If so, is
         the EMR package a true, legal medical record?
     B. If not, what EMR system is supported by your software? Does that systems provide
         seamless connectivity?
     C. Please discuss how the EMR contained within or supported by your software closely
         relates to a paper medical record.
     D. Can scanned forms be parsed to create database searching capabilities on those forms.
     E. Does your system provide integrated SOAP notes? In what way?

8.   Future
     A. What type of interfaces exists now or in the future utilizing input equipment such as
         scanners, wands, card swipes, etc.
     B. Can/will the system facilitate automated telephone inquiries for test/lab results.
         Can/will the system be able to make automated calls to deliver these results.
     C. Will this software package have the ability to send a reminder (by email or print a
         letter) to patients that have a charge to pay.
     D. Will your system now or in the future support voice recognition software for
         dictation?
     E. What web technologies are you looking at to enhance your product in the future?
     F. In what ways are the following being considered by the company:
          Web-based Account Balances
          Updating Insurance Information
          E-commerce (payment of account balances)
          Online Appointments Scheduling
          Electronic Encounter forms
          Online Lab Test Results
          Self Check-in (Swiping the Student’s ID Card) & Triage
          Ask-a-Nurse Capabilities
          Electronic Medical Records

Student Health Technological Advancement Endeavor          Revised: 12/3/2011               19
                                            Section IV – PUSH System Specifications

            Ability to email statements, notices, prescription, and immunization alerts

9.   Requisition Capabilities for Ancillary Services
     A. Is your system a comprehensive clinical package providing seamless and integrated
        requisition modules for Laboratory, Pharmacy, X-Ray and Physical Therapy?
     B. If so, explain how your software provides for making requisitions to those
        departments? How are results communicated back to the requesting party?
     C. Can the outside referring physician be listed on printed labels? The current system
        only prints “Outside Physician” and not the actual provider’s name.
     D. Is there a place to enter comments that will be printed on the requisition slip?

10. Reporting
    A. Does your system have the ability to directly populate cells in an Excel Spreadsheet in
       its reporting package through OLE or ActiveX controls?
    B. How many canned reports come with the system?
    C. Can your system create real-time graphs within the system in its reporting package?
    D. Is it possible, within your system, to print reports to a file rather than to a printer?
    E. Is it necessary to have people off the system during month end and daily routines?
    F. Does your system provide built-in management, trends analysis, financial, clinical,
       immunization, A/R reporting, journal entry, audit analysis, and transaction summaries
       reports?
    G. Does the system have the ability to track primary referring physicians such as; which
       providers refer the most? Does it track the number of authorized visits for a patient
       and decrease that amount for each visit by that patient?
    H. What program is used to create custom reports?
    I. Does the software use standard Windows Printer Drivers or their own specific
       drivers?
    J. Can the system generate queued reports unattended and after-hours?
    K. By what method can we create and use reports?

11. Software/Hardware Specifications
    A. Please provide recommended specifications for a server for your software?
    B. What specifications do you recommend for workstations?
    C. What program is the software written in?
    D. What type of database is used by the system?
    E. Are ‘dongles’ used to physically validate licensing?
    F. What method does the company recommend for disaster recovery solutions?
    G. What disk method (i.e. - RAID) does the company recommend to ensure data
        integrity?




Student Health Technological Advancement Endeavor          Revised: 12/3/2011                 20
                                           Section IV – PUSH System Specifications

                               ACCOUNTS RECEIVABLE

12. Account Set-up Information.
    A. Does the customer address fields allow for an additional (alternate) address for each
        customer?
    B. What is the account number layout? Does the system allow for alternate (multiple)
        account number fields per customer?
    C. Does the system assign a separate invoice or document number to each charge
        transaction?
    D. Does the customer set-up allow for a Social Security number field?
    E. Does the customer set-up allow for telephone and alternate telephone fields, e-mail
        address fields?

13. Billing Process.
    A. Can the software bill the primary, secondary and tertiary insurances?
    B. How are charges accumulated and entered to the receivable module?
    C. Do individual invoices correspond to a single charge transaction? Explain what
         constitutes an individual invoice on a customer account.
    D. What is the limit of the number of invoices per customer account?
    E. Are individual invoices maintained separately under the customer’s account?
    F. Does the system allow for batch processing of invoices and on demand of individual
         invoices?
    G. Explain how an initial invoice/billing is generated?
    H. Explain how the system handles follow-up billing statements, frequency of follow-up,
         etc.
    I. What information does an initial invoice/billing contain? Billing dates/Due
         dates/Payment terms/description of services, etc. Provide a copy of an initial
         invoice.
    J. What information is included on follow-up bills/statements? Are follow-up
         statements a different format from the initial invoice? Provide a copy of a follow-up
         billing statement.
    K. Does the system allow the flexibility to generate billings by invoice (per transaction)
         or by a consolidated statement, which includes a summary of all invoices?
    L. Can invoices and follow-up billings be customized per Purdue’s specifications? Are
         bill formats defined by the user, for example, can the user make changes without
         vendor re-programming?
    M. Can copies of invoices and statements be re-printed at any time?

14. Collection.
    A. Explain how payments are applied in the system. Are payments applied directly to
        individual customer invoices or to the customer account? If payments are not applied



Student Health Technological Advancement Endeavor         Revised: 12/3/2011               21
                                            Section IV – PUSH System Specifications

         directly to customer invoice, explain how the system applies a payment to a customer
         account that includes multiple invoices.
    B.   Are payments entered via a batch process? Or are payments entered individually to
         customer accounts? Please explain.
    C.   Does the system identify method of payment, for example, cash, check, credit card,
         insurance payment, etc.?
    D.   Does the system provide an aging analysis of open invoice items?
    E.   What is the aging of open items based upon? Invoice date, due date, etc?
    F.   Is aging analysis user controlled? Please explain.
    G.   What is the format of the aging periods, and how many aging categories are
         provided? For example; current, 0-29 days past due, 30-59 days past due, 60-89 days
         past due, 90 days and over.
    H.   Explain what aging reports are generated by the system. Provide examples of the
         aging reports.
    I.   Does the system provide any special customer notifications on past due balances?
         Please explain and/or provide examples.
    J.   Is the receivable module capable of setting up installment pay plan arrangements?
         Please explain.
    K.   Does the receivable module allow for interest computation and/or a one-time late
         penalty fee on past due balances? Can this function be applied by individual
         invoices?
    L.   Can individual invoices be coded so that follow-up billings are not generated? Please
         explain.
    M.   Does the system provide a “comments” screen to record customer and collection
         notes, conversations, etc.? How long do these notes remain on the file until they are
         purged?

15. Miscellaneous.
    A. Please explain how the receivable module handles overpayments (credit balances)?
        Are there separate fields that record a credit balance for a customer? Are credit
        balances recorded by individual invoice or in aggregate by customer account?
    B. Can multiple users access and inquire on an account at the same time?
    C. Does the system provide a historical file (ledger) of charges, payments, adjustments,
        etc. in date order of transactions? How long does this data remain on-line before it is
        purged?
    D. Are individual data entry transactions identified by user name or code?
    E. Explain the internal controls present in the system to operate the A/R portion of the
        system. For example, can the system security assign by user, access to specific
        financial functions, such as;
         Entering charges.
         Generating bills.
         Payment application.


Student Health Technological Advancement Endeavor           Revised: 12/3/2011               22
                                            Section IV – PUSH System Specifications

          Entering account adjustments, canceling charges.
          Inquiry only.
    F.   Does the system provide some type of closing or posting routines on a daily, monthly,
         and annual basis? For example, is there a posting routine for charges billed, payments
         applied, adjustments, etc. If so, please explain.
    G.   Does the system provide standard reports to support the A/R function for data entry of
         transactions, daily balancing, reconciling, auditing, and management analysis? If so,
         please explain and provide examples.
    H.   Is the system capable of generating E-mail alerts to customers for collections and
         miscellaneous communications?
    I.   Has your system been installed for other customers that included integration of
         receivable data to another billing system? If so, please provide company name and
         contact.
    J.   Does the system allow for interfacing of accounts receivable data to the University
         student receivable system? If so, what specific data fields are typically transmitted to
         the student receivable system? For example, charges, payments, charge adjustments,
         payment adjustments, etc.
    K.   Is the system capable of transferring charges to the student system for select accounts
         or is the transfer an all-or-nothing transfer? Can the system transfer to the student
         receivable system based upon age of charge or past-due status?
    L.   Will the initial development of the interface for the transmission of data to and from
         your software product to other University systems be included in the initial purchase
         agreement and implementation?
    M.   Is this included in the initial cost of the software?
    N.   If these interfaces require modifications at a later time, what development process
         will be involved and costs incurred?




Student Health Technological Advancement Endeavor           Revised: 12/3/2011                23
                                                 Appendix A – Operating Environment

                                         Appendix A
                               OPERATING ENVIRONMENT

Workstation Operating System
Windows2000 Professional.

Workstation Hardware
The only workstation hardware related to this project is personal computers. Approximately 80
PCs, Pentium III 450s or higher.

Database software
Oracle has been selected as the standard database software to develop major applications.

Server hardware and software
A UNIX server running AIX (version 4.3) is currently used to run the Dataflow system.

E-Commerce
For credit card authorization via the web, an in-house server is used.

Mail Services
Simple Mail Transfer Protocol (SMTP) is the standard mail protocol used.

Network protocol
The standard Purdue University protocol used for the network is TCP/IP.

File Transfer
File transfer protocol (FTP) is the primary method used to transfer files from one computing
platform to another.

Languages
Programming languages to develop systems in Management Information are COBOL, COBOL
II, COBOL Micro Focus, PowerBuilder, SQL, Visual Basic, C and Small Talk.

Office Productivity
Office 2000 is the product suite supported for the office tools.         Internet Explorer is the
standardized browser choice.

Printing
Dot-matrix printers - 19
Lasers:
 2 - HP LJ II


Student Health Technological Advancement Endeavor            Revised: 12/3/2011               24
                                           Appendix A – Operating Environment

   4 - HP LJ 4050
   1 - IBM Laser
   2 - HP Color LJ 4500
   2 - HP LJ 4
   1 - HP LJ 5siMX

LAN & Directory Services
Novell 5 using NDS is our standard.




Student Health Technological Advancement Endeavor   Revised: 12/3/2011     25
                                                 Appendix B – Notice of Intent Form

                                      Appendix B
                              NOTICE OF INTENT FORM


             Yes, we intend to submit a proposal in response to the above RFP.

             No, we do not intend to submit a proposal

             Company

             Vendor Contact Person

             Title

             Address


             City/State/Zip

             Phone

             Fax

             Email Address


             Submitted By
                                            (please print or type)

             Title

             Date


NOTE:    Return this form by fax not later than Monday, July 6, 2001 to:
                                   Purdue University
                                   Purchasing Department
                                   1067 Frehafer Hall
                                   401 South Grant Street
                                   West Lafayette, IN 47907-1067
                                   Attn: Eric E. Fulkerson
                                   Fax: (765) 494-6609

Student Health Technological Advancement Endeavor           Revised: 12/3/2011   26
                                     Appendix C – Security Questions/Specifications

                                         Appendix C
                       SECURITY QUESTIONS/SPECIFICATIONS

1.   Server Security Assessment
     A. Describe how the server is physically secured.
     B. Describe the system logging and review process.
     C. How is employee contact with the server limited?
     D. Please describe any account on the secured server for which more that one person has
         access. This includes accounts like Anonymous, Guest, Everyone, etc.
     E. How is the password file secured?
     F. Purdue classifies the personal information you will collect on its behalf to be sensitive
         in nature. How will you ensure that only authorized individuals and programs have
         access to this sensitive information?
     G. How will PUSH access and/or obtain the e-commerce information?
     H. Describe all connections to the secured server (dial-in/out, 3rd party, Internet, local).
     I. Describe the security in place to restrict/monitor access.
     J. What data will be stored on the server?
     K. What services are running on the server? (FTP, TFTP, UUCP, -r commands, telnet,
         sendmail, etc.)
     L. Is there any firewall protecting the server? (packet filter, application gateway, etc.)
     M. Has any vulnerability testing been run on the server?
     N. If remote support access is required, how will you ensure that only authorized
         individuals and programs have access to... (7 would not necessarily be applicable to
         this system) the rest are fine
     O. What recommendations does the company have for Disaster Recovery options?

2.   Application Security
     A. How does the authentication work for this application?
     B. How does the user setup facilitate limiting access to menu items or classes or data?
     C. How does the application encrypt sensitive or restricted data for transmission or
        storage?
     D. Does the application have any 'hooks' into the operating system that would pose a
        problem to future upgrades of the operating system?
     E. Does the application work properly with monitoring software installed (TCP
        Wrapper, TCP Dump, Tripwire, CGIWRAP, etc.)?
     F. Does the application require users other than the system administrator to have any
        direct access to the operating system?
     G. Does the application contain an inactivity time-out feature?
     H. Are any shared accounts required for the application to run properly?
     I. What password control features are available (password aging, special characters
        required, maximum number of password attempts, etc.)?


Student Health Technological Advancement Endeavor           Revised: 12/3/2011                 27
                                    Appendix C – Security Questions/Specifications

     J. Can the database be housed in a separate server from the application? When web
        based features are present, can the web server be separate from the application and
        database server?
     K. Describe the audit trails available within the application.

3.   General Security Questions
     A. How are security problems, once identified, resolved?
     B. How are security problems communicated to other sites using the application?




Student Health Technological Advancement Endeavor          Revised: 12/3/2011                 28
                                               Appendix D – Data Field Requirements

                                         Appendix D
                              DATA FIELD REQUIREMENTS

Some of the fields necessary are those listed below.

   Patient Information
   Patient Name (first name, middle initial, last name)
   Local Address
   Permanent Address
   Student ID
   Social Security Number
   Insurance (multiple)
   Phone (local & permanent)
   Birth date
   Age
   Gender
   Marriage status
   Standard Physician
   Status in School (full-fee, non-fee, staff)
   Guarantor
   Immunization fields

Currently, these data fields are required within Dataflow, should your software require the
same fields and/or a better approach that would support process improvement the PUSH staff
would gladly welcome any suggestions.




Student Health Technological Advancement Endeavor          Revised: 12/3/2011           29
                                                           Appendix E – Project Charter

                                         Appendix E
                                   PROJECT CHARTER

Introduction
We propose to the University an undertaking to search and procure a new medical management
software package to replace the Dataflow system currently in use at the Student Health Center
(PUSH). We feel that we have reached the limits of this current software package and that we
can no longer upgrade or update our software to further enhance service to the student
population and respond to innovative changes in technology.

With this charter, we hope to define the extent of the project as it relates to the University,
including the current conditions of the software in place and how we got there, the objectives
and the benefits of replacing the current software, the scope of the project, expectations from a
new software package and those deliverables which must be met by it, and the risks possible
for not replacing our current software package. The Charter will also assist with the
establishment of specific work criteria to complete this project.

Project Background
The Dataflow software system was implemented in approximately 1994 by the vendor,
Companion Technologies and a project team here at Purdue. With it, PUSH tracks patient’s
medical visits, diagnoses and procedures, charges incurred, and billing. Dataflow promised to
allow PUSH to implement a simple level of security so that medical records could remain
confidential and setup a simple method of keeping an audit trail of activity in the system.

Several modifications to the software were created by Companion Technologies at the request
of the Purdue project team to facilitate necessary transfers of core, University data to and from
Office of the Registrar and University Collections (CARS). These modified program blocks
take internal Dataflow data and format it in a way that the receiving system (at CARS or SITP)
can import. Likewise, these modified program blocks format incoming data in a way readable
by the Dataflow system. These modifications allow;
1. for PUSH to meet centralized billing standards on campus, through CARS, and enables the
     University to post encumbrances and accept payments from other areas of the campus
     besides PUSH.
2. for PUSH to provide state mandated immunization notification to Registrar and receive
     student demographics.

Throughout the Dataflow life cycle and especially in the last year, PUSH is continuing to
experience the limitations of this software package. This is becoming increasingly apparent in
several areas of the package:
1. The aforementioned auditing features are increasingly unreliable and are not detailed
    enough to meet expectations or desires. Manual, paper procedures must accompany
    electronic procedures in order to form semi-reliable audit trails. Requiring staff to

Student Health Technological Advancement Endeavor           Revised: 12/3/2011               30
                                                          Appendix E – Project Charter

     ‘double-check’ computer programming negates the simplicity of using computer software
     and creates inefficiencies within the business processes. With the auditing features
     available within Dataflow, PUSH is unable to capture all the information it requires for
     usable audit trails.
2.   The original modifications to transfer data have never been 100 percent dependable.
     Important information, at times, has been lost, duplicated, or changed within the
     formatting process of these modified program blocks created by Dataflow. For this
     reason, manual procedures have been put into practice. Again, PUSH staff are required to
     ‘double-check’ information.
3.   The reporting features within Dataflow give variable data from one report to the next.
     Dataflow reports have been compared to the manual logs by PUSH and in many cases
     found to be inaccurate to actual data. Over time, these reports have become less trusted.
4.   Situations have occurred where the updates/upgrades from Companion Technologies were
     more destructive to the software package and business process than an enhancement.
     Many weeks, if not months after an update or upgrade, PUSH must still continue working
     with the vendor to resolve problems or request the reprogramming of code.
5.   Clear examples can be shown where the security schemes, as required by PUSH, cannot be
     implemented by Companion Technologies or their software package, Dataflow. While a
     simple security structure has been created, the Dataflow software simply does not allow
     the ability to set up a more secure and reliable structure that satisfies our requirements.
6.   Dataflow database tables are not compatible with current, software-industry database
     structures. Due to this vendor specific database, PUSH cannot take advantage of any new
     technology including web-based information systems and documentation imaging systems.

Companion Technologies is currently the owner of the Dataflow software. Over the years,
PUSH has become aware of large staff restructuring and turnover within Companion
Technologies. This has been most apparent in a few of the following areas:
1. Support from the company has been clumsy at best. All calls are routed through a
    helpdesk operator. This operator creates a work task and sends this to the appropriate
    team. Certain teams at Companion Technologies are negligent at returning calls.
    Unfortunately, it is those teams that PUSH relies on more often for help.
2. If the support team does return the call, it is not unusual for more than an hour or two to
    have passed even on priority requests.
3. When combining the annual licensures and the current pricing structure for support, the
    cost verses support ratio is very high for amount of support received.
4. As of the date of this Project Charter, Companion Technologies has missed a due date to
    reprogram critical modules within the Dataflow system for PUSH by more than half a
    year. Calls to request status of these projects go unanswered.




Student Health Technological Advancement Endeavor           Revised: 12/3/2011              31
                                                            Appendix E – Project Charter

Objectives
The objective of this project is to purchase a medical management software package that:
1. Will give the staff and providers a better tool to care for the student population and more
    quickly respond to their health needs.
2. Can be more easily updated to reflect the needs of the center.
3. Allows PUSH to position itself to take advantage of new electronic imaging, automation,
    and web technology.
4. Generates accurate reports and statistics to help PUSH better determine future direction
    and need.
5. Increases efficiency, accuracy and flexibility with state-of-the-art medical management
    software designed for outpatient clinics. At a minimum, the software will
     Track patient’s medical visits.
     Schedule appointments.
     Print labels, patient statements, encounter forms, receipts, etc.
     Provide statistical and financial reports.
     Interface with University departments.
     Allow electronic billing.
     Support ancillary services.
     Provide a user-friendly, Windows-based graphical user interface.
     Support Web-based features.
     Handle electronic medical records.
6. Generates more reliable data and smoothly transfer this data to and from CARS and
    Registrar.
7. Meets the needs of PUSH so that costly and time-consuming modifications can be
    avoided.
8. Establishes a partnership with a vendor who readily supports its software and responds to
    the needs and requests of their clients. A vendor that will remain its own entity and retain
    control of its own future and software packages.
9. Standalone separately identified entity that does not house other University applications or
    data.

Scope
Several University departments are ‘touched’ by this project, each for a particular reason.
The Student Health Center will be the department to receive this software. It will be PUSH
that will ultimately learn to use this software and be on the frontline to maintain the data stored
in the system.
Student Services Computing Zone is affected in that it supports the desktops used in the
building. They will be responsible to maintain those desktops that are the links to the medical
management software. Currently, all workstations housed at PUSH meet most vendor
specifications to run their software.



Student Health Technological Advancement Endeavor             Revised: 12/3/2011                32
                                                                                 Appendix E – Project Charter

Management Information will be involved in that they will house and maintain the servers,
be it Unix- or NT-based, on which the medical management software and data resides. In
addition to this during the vendor demonstrations, individuals representing certain areas at MI
(NT, Unix, Security, DBA, Applications) will be invited to help evaluate vendor software
products.
Internal Audit will be scrutinizing the software choices to determine whether the packages are
compliant to University standards in the way of audit trails and security.
Central Accounts Receivable must be involved to help determine the reliability of the system
to transfer charges and payment information. Three options in this area exist:
1. PUSH transfers all charges and payments to CARS to be handled by the University
2. PUSH retains all charges and payments and age’s accounts internally.
3. PUSH ages account, internally for a specified time, then transfers account information to
CARS.
Registrar needs to be on the committee to help with transfer of student demographics and
immunization records.
Purchasing will help in securing an agreeable contract with the vendor selected.
The future plans concerning Document Imaging should also be considered during this software
selection process if PUSH determines to move to an Electronic Medical Records format.

Assumptions
1. The new medical management software system will continue to be supported and
    maintained as a departmental application with secondary support from Management
    Information (consistent with current practice).
2. All hardware and operating system administration needs will be met by Management
    Information.
3. Database Administration needs will be met by the chosen vendor and Management
    Information.
4. All support and maintenance of the application software will be done by the vendor.

Schedule
 Create Project Charter ..................................................................................................... Done
 Determine and establish Executive Sponsor ................................................................... Done
 Submit Project Charter to Executive Sponsors ............................................................... Done
 Determine and establish the Steering Committee and Project Team .......................... Revised
 Survey Project Scope and Feasibility .............................................................................. Done
 Study Current System ...................................................................................................... Done
 RFI via Scheduled onsite demonstrations with vendors.................................................. April
 Create RFP................................................................................................................ May/June
 Submit RFP to Steering Committee ..................................................................................June


Student Health Technological Advancement Endeavor                                  Revised: 12/3/2011                            33
                                                                                 Appendix E – Project Charter

   Send RFP to vendors (with 30 day return request) .................................................... June/July
   Review returned RFPs .................................................................................................. August
   Select Vendor/Software .............................................................................. August/September
   Submit choice(s) to Steering Committee ................................................................. September
   Contact Purchasing to draft proposal to chosen vendor ............................ September/October
   Sign agreement ............................................................................................................ October
   Plan Implementation with vendor/Process Redesign ................................ October/November
   Implement Training of users ........................................... November/December/January 2002
   Implement Software .......................................................... December/January 2002/February
   Assess implementation ................................................................................... February/March
   Future Direction Development ...................................................................................... March
   Currently determining feasibility of electronic imaging, automation, and web technology.

Deliverables
1. Project Charter submitted in final draft to the Executive Sponsors and committee
    organized.
2. RFP submitted in final draft to Steering Committee and Purchasing.
3. RFPs returned from vendors.
4. Vendor demonstrations schedule and completed. Information disseminated to those
    people necessary to help finalize a decision.
5. Purchasing contacted and contract created and signed.
6. Implementation plan including testing, training, data conversion, support & maintenance
    plans
7. Install new software and train PUSH users
8. Phase out existing software package.
9. Determine future projects

Risks
If a new software package is not purchased, the following risk factors are possible.
1. Less-than-optimal customer service as a result of downtime.
2. Locked into a system that cannot be updated
3. Unreliable statistical data or loss of data.
4. Risk of being out of medical and/or state medical compliance (i.e. – immunizations)
5. Possible loss of revenues
6. Lack of detailed audit trail and possibility of compromised security to the system.

Benefits
If a new software package is purchased, the following benefits may be realized.
1. Enhanced revenue tracking.
2. Reduced costs in maintaining the system, postage with electronic billing.
3. Increased customer service; accurate statements, timely billings


Student Health Technological Advancement Endeavor                                   Revised: 12/3/2011                             34
                                                        Appendix E – Project Charter

4.   Smooth transfer of data to other University departments.
5.   Ability to trace all activity with a date/time-stamped audit trail.
6.   Reliable system both in hardware (less downtime) and data (accurate reports)
7.   Ability to move further than currently possible into the technological future (i.e. EMR,
     Card Swipes, Web technology, etc.)




Student Health Technological Advancement Endeavor         Revised: 12/3/2011              35
                                      Appendix F – Professional Services Agreement
File: 103102
Reference:n/a



                       PROFESSIONAL SERVICES AGREEMENT
                               AND PURDUE UNIVERSITY


This Agreement is made this day,            ,       by and between [insert company name &
address], hereinafter referred to as “Supplier” and Purdue University, West Lafayette, Indiana
47907, hereinafter referred to as “Purdue”.

WITNESSETH

In consideration of our mutual promises and understandings as hereinafter set forth, it is
mutually understood and agreed as follows:

1.   PROJECT OBJECTIVE:

2.   TERM: The term of this Agreement shall be                through          , unless terminated
     sooner as provided herein.

3.   SCOPE: During the term of this Agreement, Supplier shall provide to Purdue the
     professional services set forth in Attachment A. Supplier will be readily available to
     provide and complete such services in accordance with a mutually acceptable schedule.
     Supplier agrees that, in furnishing the services hereunder, it shall be acting as an
     independent contractor in relation to Purdue and not as an employee or other agent of
     Purdue. Supplier shall have no authority to act for or on behalf of Purdue or to bind Purdue
     without Purdue's prior express written consent. Supplier acknowledges that it is
     responsible for its own federal, state and local income, social security, unemployment and
     all other applicable taxes.

4.   COMPENSATION:
     a. The fee for the services defined in Section 3 above shall be       .

     b. Purdue agrees to reimburse Supplier, for all necessary, actual and reasonable expenses
        incurred in performing the services provided hereunder, including but not limited to
        coach airfare, food, lodging, rental car or taxi, copy or reproduction charges, and long-
        distance phone charges, if any.

     c. Invoices will be issued monthly based on work completed. Terms are net 30.


Student Health Technological Advancement Endeavor           Revised: 12/3/2011                 36
                                     Appendix F – Professional Services Agreement


5.    KEY PERSON(S):
     a. In the event that both parties have designated in an appendix that individual(s) therein
        named are essential to the services offered pursuant to this Agreement, the parties
        agree that if such individual or individuals no longer be employed during the term of
        this Agreement by Supplier for whatever reasons, Purdue shall have the right to
        terminate this Agreement upon thirty (30) days prior written notice.

     b. Nothing in subsection a above should be construed to prevent Supplier from using the
        services of others to perform tasks ancillary to those tasks which directly require the
        expertise of the key person. Examples of such ancillary tasks include secretarial,
        clerical and common labor duties. Supplier shall at all times remain responsible for
        the performance of all necessary tasks, whether performed by a key person or others.

6.   CONTRACTOR PERSONNEL:
     a. Supplier shall at all times employ qualified and sufficient personnel to perform the
        contracted services in the manner and within the period of time requested by Purdue.
        Supplier further understands that Purdue has relied on the qualifications and
        experience of Supplier personnel as the primary basis for awarding this Agreement.
        Accordingly, if certain personnel are requested by Purdue to perform a specific task,
        then said personnel shall be assigned to perform the task unless the employee(s) is
        terminated or resigns from employment. If an employee terminates or resigns from
        employment with Supplier, Supplier shall promptly replace the employee with a
        person of equal or greater skill and expertise. Purdue must approve such replacement.
        Supplier shall bear all cost and responsibility for insuring that replacement personnel
        are trained and adequately prepared to assume all responsibilities of the previously
        assigned employee.

     b. Any person assigned by Supplier shall, at the written request of Purdue, be removed
        forthwith by Supplier. If the person is not removed or if replacement personnel are
        deemed unsuitable for proper completion of the work, the work may be suspended by
        written notice until the requirements have been met or if such request by Purdue is not
        met, Purdue will not be responsible for any charges associated with work performed
        by non-approved personnel.

7.   TERMINATION:
     a. Purdue may terminate and cancel this Agreement without prejudice to any rights or
        cause of action Purdue may have against Supplier, if Supplier is adjudged bankrupt; or
        Supplier makes a general assignment for the benefit of creditors; or receiver is
        appointed due to Supplier insolvency; or a court of competent jurisdiction finds that
        Supplier persistently disregards laws, ordinances, rules, regulations, or orders of any
        public authority having jurisdiction.


Student Health Technological Advancement Endeavor           Revised: 12/3/2011              37
                                     Appendix F – Professional Services Agreement


     b. Purdue, in addition to other rights set forth elsewhere in the Agreement, may terminate
        the whole or any part of this Agreement at any time if Purdue determines that Supplier
        has failed to make satisfactory progress toward performance. In such a case, Purdue
        will transmit a Termination Notice of the default of Supplier by certified mail, return
        receipt requested, at least ten (10) days prior to termination date, and the Agreement
        shall be terminated effective on the date specified in Purdue’s notice. Supplier shall
        continue Agreement performance to the extent not terminated under the provision of
        the above paragraph and shall be compensated for its performance pursuant to the
        rates set forth herein. In the event that Purdue terminated the Agreement, in whole or
        in part as provided in this clause, Purdue may procure, upon such terms and in such
        manner as it may deem appropriate, services similar to those so terminated, and
        Supplier shall be liable to Purdue for reasonable costs for such similar services. The
        rights and remedies of Purdue provided herein shall not be exclusive and are in
        addition to any other rights and remedies provided by law or under this Agreement.

8.   TERMINATION FOR CONVENIENCE:
     After the initial work phase, the performance of services under this Agreement may be
     terminated, in whole or in part, if Purdue determines that such termination is in the best
     interest of Purdue. Termination of work shall be effected by delivery to Supplier of a
     termination notice at least thirty (30) days prior to the termination effective date,
     specifying the extent to which performance of work under the Agreement is terminated
     and the date upon which such termination becomes effective. Supplier shall be
     compensated for services provided, but in no case shall payment exceed the Agreement
     price approved up to the date of termination.

9.   RECORDS AND AUDITS: Supplier shall maintain a thorough and complete record of its
     hours of service performed for Purdue under this Agreement and the reasonable business
     expenses incurred by it in connection with the services performed under this Agreement.
     Time records shall be kept to the closest quarter hour during each day that Supplier
     performs services under this Agreement. Supplier agrees to cooperate with Purdue in any
     audit or review relating to the provision of services pursuant to this Agreement. Purdue
     shall have the right, upon reasonable notice, to audit at any time up to 6 years after
     payment of its final invoice, the direct costs, expenses, and disbursements made or
     incurred in connection with the services to be performed herein and the basis on which the
     costs were derived and may examine Supplier’s records and books relating to these
     several areas.

10. WARRANTIES AND INSPECTION: Supplier warrants that all services performed
    under this Agreement shall be performed in a good and workmanlike manner and shall
    conform to the specifications, drawings, samples, other description, and terms and
    conditions contained or referenced herein. Supplier further warrants that all services


Student Health Technological Advancement Endeavor          Revised: 12/3/2011              38
                                      Appendix F – Professional Services Agreement

    performed under this Agreement shall comply with any and all building laws, ordinances,
    and regulations of any and all governmental agencies entitled to impose such laws,
    ordinances and regulations and shall comply with Purdue’s standard and rules and
    regulations. All services shall be subject to Purdue’s inspection before acceptance, and
    payment for services rendered shall not constitute a waiver of any of the rights granted to
    Purdue under this section.

11. RIGHTS IN THE WORK PRODUCT: Purdue shall own all right, title, and interest in
    and to any Work Product produced by Supplier under this Agreement, and Supplier agrees
    that such Work Product shall be deemed a "work made for hire". Supplier will execute any
    necessary confirmatory assignments to Purdue to effectuate the foregoing. "Work Product"
    is defined as all data, documentation, software, information, or other deliverable, in
    whatever form, produced or created by Supplier in the performance of work or the
    rendition of services under this Agreement.

12. CONFIDENTIALITY: During the term of this Agreement and thereafter, Supplier shall
    not disclose or use for the benefit of other than Purdue any confidential or proprietary
    information disclosed to Supplier as a result of this Agreement. Supplier represents that it
    does not have in its possession and has not used for the benefit of Purdue any confidential
    information or documents belonging to others. Supplier represents that its retention by
    Purdue will not require it to violate any obligation to others, under agreement or otherwise,
    or to violate any confidence of others. Supplier knows of no written or oral agreement or
    of any other impediment which would inhibit or prohibit the relationship with Purdue
    provided for herein. Supplier represents that it will not, by signing this Agreement or
    performing the services provided for herein, violate any rights, including but not limited to
    intellectual property rights such as trademark, trade secret and copyright, of any other
    individual or entity.

13. GOVERNING LAW; EXCLUSIVE JURISDICTION; EXCLUSIVE VENUE: This
    Agreement is entered into in Indiana and shall be governed by and construed in
    accordance with the substantive law (and not the law of conflicts) of the State of Indiana.
    Courts of competent authority located in Tippecanoe County, Indiana shall have sole and
    exclusive jurisdiction of any action arising out of or in connection with this Agreement,
    and such courts shall be the sole and exclusive venue for any such action.

14. COMPLIANCE WITH GOVERNMENT STATUTES AND REGULATIONS:
    Supplier warrants and certifies that in the performance of this Agreement it has complied
    with or will comply with all applicable statutes, rules, regulations and orders of the United
    States, and any state or political subdivision thereof, including laws and regulations
    pertaining to labor, wages, hours and other conditions of employment, and applicable price
    ceilings, if any, and that the goods or services delivered hereunder shall be produced or
    performed in compliance with the Fair Labor Standards Act.


Student Health Technological Advancement Endeavor           Revised: 12/3/2011               39
                                       Appendix F – Professional Services Agreement


15. INDEMNIFICATION: Supplier agrees to indemnify Purdue and hold it harmless from
    and against all liability, losses, damages, claims, liens, and expense (including reasonable
    legal fees) arising out of or connected with the work or services performed, or resulting
    from damages or injuries incurred by Purdue by reason of any defect in material,
    workmanship, and/or design of any goods furnished hereunder, excepting only such
    liability as may result solely from the acts of negligence of Purdue or its employees.
    Supplier shall at the request of Purdue undertake to defend any and all suits and to
    investigate and to defend any and all claims whether justified or not, if such claim or suit
    be against Purdue, the Trustees of Purdue, or their respective officers, agents servants, and
    employees.

16. INSURANCE: If fabrication, construction, installation, service or other work is specified
    to be conducted on Purdue's premises, Supplier and/or its subcontractor(s), if any, shall
    maintain in force during the period of such work the following coverages: (a) worker's
    compensation, as required by the laws of the State of Indiana; (b) commercial general
    liability for bodily injury and/or property damage in an amount of not less than $1,000,000
    single limit, per occurrence; (c) automobile liability for bodily injury and/or property
    damage in an amount of not less than $1,000,000 single limit, per occurrence. Upon
    request by Purdue, Supplier and/or its subcontractor (s) shall furnish to Purdue satisfactory
    proof of such insurance coverages prior to commencement of the work.

17. NONDISCRIMINATION:                Supplier, or its subcontractor(s), if any, shall not
    discriminate against any qualified employee or applicant for employment to be employed
    in the performance of this Agreement, with respect to hire, tenure, terms, conditions, or
    privileges of employment, or any matter directly or indirectly related to employment
    because of race, religion, color, sex, disability, national origin, or ancestry. Supplier, or its
    subcontractor(s), if any, agrees to comply with all the provisions contained in the Equal
    Opportunity Clause, quoted in Executive Orders No. 11246 and No. 11375, and contained
    in the Indiana Civil Rights Law, quoted in IC 1981, 22-9-1-10, as amended; The
    Americans with Disabilities Act of 1990 (ADA) which are hereby incorporated in this
    Agreement by reference. As used therein the word "contractor" shall be deemed to mean
    "Supplier," and the word "contract " shall refer to this Agreement. In addition, Supplier
    shall cause the Equal Opportunity Clause and the ADA to be included in their subcontracts
    or purchase orders hereunder unless exempted by rules, regulations and orders of the
    Secretary of Labor issued pursuant to Section 204 of the Executive Orders No. 11246 and
    No. 11375 as amended.

18. ADVERTISING: Supplier agrees not to make reference to Purdue in any advertising
    material of any kind and further agrees not to use Purdue's logos, trademarks and
    tradenames without prior written permission by Purdue.



Student Health Technological Advancement Endeavor              Revised: 12/3/2011                40
                                       Appendix F – Professional Services Agreement

19. CONFLICT OF INTEREST: An Indiana criminal statute (IC 35-44-1-3) prohibits
    public servants from knowingly or intentionally having a pecuniary interest in, or deriving
    a profit from, any Agreement or purchase connected with an action by the governmental
    entity which such person serves, with certain stated exceptions. Accordingly, if any
    person having any interest in Supplier is an officer or employee of Purdue, disclosure of
    this fact must be made so that the possible application of this statute may be investigated.

20. REGISTRATION: The Indiana Business Corporation Law requires that certain foreign
    corporations (i.e., corporations not incorporated under the said Indiana Law) organized for
    profit, if not already qualified to transact business in Indiana, must procure a certificate of
    admission from the Secretary of State of Indiana, before transacting any business in said
    State. Information concerning this statute and its administration, and penalties for non-
    compliance, may be obtained through the Office of the Secretary of State.

21. WITHHOLDING: Purdue is required by laws of the State of Indiana to withhold
    specified percentages of all amounts paid to non-resident contractors (which term does not
    include a foreign corporation qualified to do business in Indiana) for performance of
    certain agreements, excluding the first $1,000,000 paid to any such non-resident contractor
    during any calendar year. Any amounts so withheld are paid over directly to the Indiana
    Department of State Revenue.

   22. NOTICES: Any notice or other correspondence required or permitted to be given
       pursuant to this Agreement will be in writing and will be deemed to have been given if:
       (a) served personally, (b) sent by facsimile with confirmation of receipt, or (c) sent by
       first class mail, postage prepaid, to the addresses set forth below or to such other
       addresses as either party hereto may designate by notice to the other party.

                                Purdue University                   Purdue University
                                                                    University Contacting Group
                                                                    401 South Grant Street
                                                                    West Lafayette, IN 47907-1067
Attn:                           Attn:                               Attn: Thomas D. Phillips
Phone:                          Phone:                              Phone: (765) 496-3724
Fax:                            Fax:                                Fax: (765) 494-6609

23. GENERAL: In the event any party hereto pursues litigation to enforce this Agreement
    then, the prevailing party is entitled to recover reasonable attorneys' fees and court costs. If
    any provision of this Agreement is declared to be invalid by a court of competent
    jurisdiction, such provision shall be severed from this Agreement and the other provisions
    hereof shall remain in full force and effect. This Agreement contains the entire
    understanding of the parties with respect to the matter contained herein. There are no
    promises, covenants or undertakings other than those expressly set forth herein.


Student Health Technological Advancement Endeavor             Revised: 12/3/2011                41
                                    Appendix F – Professional Services Agreement

     Amendments, modifications or changes of or to this Agreement must be made in writing
     and signed by a duly authorized representative of both parties. Supplier may not assign
     any rights under this Agreement. Subject to the foregoing sentence, this Agreement shall
     be binding upon Purdue and Supplier, their successors and assigns.

24. SPECIAL PROVISIONS:                         Optional Clauses

     a. ADDITIONAL SERVICES: Listed below are the additional services available from
        Supplier. Upon request by Purdue, Supplier will prepare cost proposals for any and/or
        all of these services.

     b. PROGRESS REPORTS: Supplier will submit monthly written progress reports to
        Purdue, and report orally on progress upon request, or when conditions warrant self-
        initiation of such reports. The progress reports shall serve the purpose of assuring
        Purdue that work is progressing in line with schedule, and that completion can be
        reasonably assured not the scheduled dates.


IN WITNESS WHEREOF, the parties have caused their duly authorized representatives to
      execute this Agreement.


Purdue University


By: ______________________________              By: ______________________________

Name:                                           Name:

Title:                                          Title:

Date:                                           Date:




Student Health Technological Advancement Endeavor         Revised: 12/3/2011              42

								
To top