B01_RFP_Final.pdf

INDIAN HEALTH SERVICE

DIVISION OF ENGINEERING SERVICES

REQUEST FOR PROPOSAL 75H701-19-R-00075

INDIAN HEALTH SERVICES (IHS) ENTERPRISE COMPUTER MAINTENANCE

MANAGEMENT SYSTEM (CMMS) SYSTEM IMPLEMENTATION FOR OFFICE OF

ENVIRONMENTAL HEALTH AND ENGINEERING (OEHE)

IHS Nationwide

PROPOSAL DUE DATE: 7 October 2019 at 2:00 P.M. PDT or earlier

TABLE OF CONTENTS:

Section Taxonomy Section A Standard Form 1449 – Solicitation/Contract/Order for Commercial Items Section B Schedule of Items Section C Description and Specification (Statement of Work) Section D Packaging and Markings Section E Inspection and Acceptance Section F Deliveries or Performance Section G Contract Administration Data Section H Special Contract Requirements Section I Contract Clauses Section J List of Documents, Exhibits Section K Representations and Certifications Section L Instruction, Conditions and Notices Section M Evaluation Factors for Award

Proposals must set forth full, accurate, and complete information as required by this request for proposal (including attachments). The penalty for making false statements in proposals is prescribed in 18 U.S.C. 1001.

SOLICITATION/CONTRACT/ORDER FOR COMMERCIAL ITEMS

OFFEROR TO COMPLETE BLOCKS 12, 17, 23, 24, & 30

1. REQUISITION NUMBER PAGE 1 OF

2. CONTRACT NO. 3. AWARD/EFFECTIVE

DATE

4. ORDER NUMBER 5. SOLICITATION NUMBER 6. SOLICITATION ISSUE

DATE

7. FOR SOLICITATION

INFORMATION CALL:

a. NAME b. TELEPHONE NUMBER (No collect calls)

8. OFFER DUE DATE/

LOCAL TIME

9. ISSUED BY

13b. RATING

14. METHOD OF SOLICITATION

CODE

15. DELIVER TO 16. ADMINISTERED BY CODE

18a. PAYMENT WILL BE MADE BY CODE17a. CONTRACTOR/

OFFEROR

CODE

FACILITY

CODE

CODE

TELEPHONE NO.

17b. CHECK IF REMITTANCE IS DIFFERENT AND PUT SUCH ADDRESS IN

OFFER

18b. SUBMIT INVOICES TO ADDRESS SHOWN IN BLOCK 18a UNLESS BLOCK

BELOW IS CHECKED

RFQ IFB RFP

SEE ADDENDUM

19.

ITEM NO.

20.

SCHEDULE OF SUPPLIES/SERVICES

21.

QUANTITY

22.

UNIT

23.

UNIT PRICE

24.

AMOUNT

(Use Reverse and/or Attach Additional Sheets as Necessary)

25. ACCOUNTING AND APPROPRIATION DATA 26. TOTAL AWARD AMOUNT (For Govt. Use Only)

28. CONTRACTOR IS REQUIRED TO SIGN THIS DOCUMENT AND RETURN

COPIES TO ISSUING OFFICE. CONTRACTOR AGREES TO FURNISH AND

DELIVER ALL ITEMS SET FORTH OR OTHERWISE IDENTIFIED ABOVE AND ON ANY

ADDITIONAL SHEETS SUBJECT TO THE TERMS AND CONDITIONS SPECIFIED

29. AWARD OF CONTRACT: REF. OFFER

DATED . . YOUR OFFER ON SOLICITATION

(BLOCK 5), INCLUDING ANY ADDITIONS OR CHANGES WHICH ARE

SET FORTH HEREIN, IS ACCEPTED AS TO ITEMS:

30a. SIGNATURE OF OFFEROR/CONTRACTOR

30b. NAME AND TITLE OF SIGNER (Type or print) 30c. DATE SIGNED

31a. UNITED STATES OF AMERICA (SIGNATURE OF CONTRACTING OFFICER)

31b. NAME OF CONTRACTING OFFICER (Type or print) 31c. DATE SIGNED

AUTHORIZED FOR LOCAL REPRODUCTION

PREVIOUS EDITION IS NOT USABLE

STANDARD FORM 1449 (REV. 2/2012)

Prescribed by GSA - FAR (48 CFR) 53.212

10. THIS ACQUISITION IS UNRESTRICTED OR

NAICS:

SIZE STANDARD:

13a. THIS CONTRACT IS A

RATED ORDER UNDER

DPAS (15 CFR 700)

SET ASIDE: % FOR:

11. DELIVERY FOR FOB DESTINA-

TION UNLESS BLOCK IS

MARKED

SEE SCHEDULE

12. DISCOUNT TERMS

ARE ARE NOT ATTACHED

ARE ARE NOT ATTACHED

27a. SOLICITATION INCORPORATES BY REFERENCE FAR 52.212-1, 52.212-4. FAR 52.212-3 AND 52.212-5 ARE ATTACHED. ADDENDA

27b. CONTRACT/PURCHASE ORDER INCORPORATES BY REFERENCE FAR 52.212-4. FAR 52.212-5 IS ATTACHED. ADDENDA

8 (A)

EDWOSB

WOMEN-OWNED SMALL BUSINESS

(WOSB) ELIGIBLE UNDER THE WOMEN-OWNED

SMALL BUSINESS PROGRAM

SERVICE-DISABLED

VETERAN-OWNED

SMALL BUSINESS

HUBZONE SMALL

BUSINESS

SMALL BUSINESS

TBD 70

75H701-19-R-00075

Matthew Phelps (206)613-2153

IHS Office of Environmental Health & Engineering 5600 Fishers Lane Rockville, MD 20857

Same as Block 9.

Submit Invoice to Contracting Officer

Indian Health Service (IHS) Enterprise Computer Maintenance Management System (CMMS) System Implementation for Office of Environmental Heath and Engineering

This Request for Proposal (RFP) is being conducted using FAR Parts 12 and 15.

541512

$27.5 Million

09/06/2019

10/07/2019

02:00 PM PST

Indian Health Service - DES Seattle 701 5th Ave, Suite 1650 Seattle, WA 98104

Request for Proposal 75H701-19-R-00075 Enterprise Computer Maintenance Management System (CMMS) System Implementation

SECTION B – SCHEDULE OF ITEMS

Please see RFP Attachment J01 – Price Schedule

NOTES:

1. Offerors shall submit pricing for each line item in RFP Attachment J01. Failure to propose in this manner may result in proposal rejection. Each price shall be a fully burdened (billable rates inclusive of all costs) to cover, all direct and indirect charges, burdened to include, but not limited to the following: Direct labor, fringe benefits, materials, subcontracts, overhead, general and administrative, quality control, supervision, support functions, facilities capital, cost of money and profit. These rates shall apply on all resulting task orders issued against this contract.

2. The schedule estimated quantities are provided for evaluation purposes only. The Government is not obligated to order the estimated amounts specified in the schedule. The estimates provided do not establish any minimum purchase limit for which the Government is obligated.

SECTION C – PERFORMANCE WORK STATEMENT

Indian Health Services (IHS) Enterprise Computer Maintenance Management System (CMMS) System Implementation for Office of Environmental Health and Engineering (OEHE)

C.1 BACKGROUND

The Indian Health Service (IHS), an agency within the Department of Health and Human Services, is responsible for providing federal health services to American Indians and Alaska Natives. The IHS is the principal federal health care provider and health advocate for Indian people and its goal is to raise their health status to the highest possible level. The IHS provides a comprehensive health service delivery system for American Indians and Alaska Natives. IHS services are administered through a system of 12 Area offices and 170 IHS and tribally managed service units.

The mission of the Office of Environmental Health and Engineering (OEHE) aims to provide and operate safe buildings and patient care equipment for the delivery of health care services to Native American Indians and Alaska Natives. A Computerized Maintenance Management System (CMMS) will provide innovative ways to improve health care delivery and quality, enhance access to care, preventive maintenance, asset tracking, mobility, and modernize administrative functions for both facility and biomedical device management to meet accreditation. OEHE recognizes that a CMMS system is needed to support a more consistent and standardized process.

OEHE invites prospective offerors to provide information on a proposed approach to configure and implement an enterprise facility and biomedical solution, including related functions, tools, and services.

All responses must conform to the requirements and instructions outlined in this document.

Offerors are required to have and provide FedRAMP certification of their solution and cloud service provider (CSP). The offerors must provide either a Provisional Authority to Operate (P- ATO) or Joint Authorization Board (JAB) authorization documentation.

All proposals must include full documentation to include, conceptual network diagrams, logic/dataflow diagrams, communications protocols, user/operator guides, all information necessary for the technical evaluation team to create an accurate security assessment as well as a use/operation assessment of the system.

C.2 OBJECTIVES

The objective is to provide a CMMS platform capable of providing service desk, incident, problem, change, knowledge, configuration management, and other CMMS processes; delivered through an “off-premises” model (e.g., Software as a Service (SaaS), cloud-based offering, etc.). The solution will be a 'turn-key', fully implemented CMMS designed for healthcare facilities, including biomedical equipment, capable of providing necessary service documentation, and reports. The solution will consist of required SaaS licenses, data collection and/or data migration, and SaaS vendor support. The solution provided shall also be aligned with CMMS healthcare industry best practices and provide the flexibility necessary to enable improvements in facility and biomedical operational and service management processes, and be capable of addressing current service management initiatives, and provide a model that supports a healthcare organization by:

Licensing on a ‘concurrent’ user basis. Other licensing schema (role-based, platform based, named-user, requestor, mobile, etc.) must be explicitly described and all tiers/types of licensing/pricing submitted for review/evaluation.

Improving facility and biomedical service delivery consistency, quality and responsiveness.

Improve visibility and collaboration across facility, biomedical, and IT support tiers.

Provide reporting and analytics for facilities and biomedical teams to track and communicate the value and support efforts they provide.

Mobility functionality via iPads, Microsoft, or Android devices with offline capability and synchronization when connectivity is available.

Statutory requirements of the Centers for Medicare & Medicaid Services (CMS) Conditions of

Participation (42 USC), the Food, Drug and Cosmetic Act (21 USC), and others.

Accreditation standards of various entities such as The Joint Commission (TJC), DNV-GL

Healthcare, Accreditation Association for Ambulatory Health Care (AAAHC), and others.

Various maintenance standards/codes such as NFPA 99, NFPA 101, AAMI/ANSI EQ56, IEC

60601, and others Reporting functionality to meet the needs of the agency.

Have a fully implemented and operational system within 12 months of contract award.

The solution shall include Development, Test and Production systems, all of which are hosted as part of a FedRAMP Low or Moderate service offering with a current FedRAMP Provisional Authorization (PA).

Respondent should clearly articulate in their response their ability to fulfill the aforementioned delivery requirements.

C.3 SCOPE

The IHS CMMS project will follow a phased implementation with incremental delivery of capabilities.

This will allow lessons learned to be incorporated as additional groups are on-boarded to using the new toolset and processes. Technical capabilities will be released in phases, while the roll-out to IHS organizations shall be completed in waves.

Ideally, full implementation at IHS would span:

Across ten out of the twelve Regional Areas Offices (Albuquerque, Bemidji, Billings, California, Great Plains, Nashville, Navajo, Oklahoma, Phoenix and Portland), Alaska and Tucson may opt to adapt the same solution at a future implementation.

Implementations and trainings at the facilities within the respective Areas are at the discretion of each Area office. The training module is based on “train the trainer” and implementations can be done remotely with the assistance from Area Office staff.

Future implementations are optional and will be funded, executed at the discretion of IHS, and planned with the vendor.

Approximately 800 total users exist for Local Facility and Biomed staff at the Hospitals, Health Care Centers, Clinics, and Area Offices.

C3.1.1 Task 1 – Software as a Service (SaaS) Licensing and Support – Base Year

The contractor shall provide their license schema to accommodate 800 solution licenses, of which are valid for 12 months from the date the licenses are provided to IHS based on usage. These licenses can be comprised of user, role-based, or concurrent in order to benefit IHS and the government. The Contractor shall propose a delivery schedule in support of required licenses to support the Contractor’s delivery of the required IHS CMMS Capabilities and Waves the Base Period of Performance. The contractor is authorized to propose additional licenses to account for organizational growth, of which shall not exceed 10% of the total required license count provided within the PWS.

Licensing shall include support from the SaaS vendor to include access to vendor support via a self-service portal and toll-free support line. Vendor support personnel will be available to assist in resolving software errors, answering questions regarding installation procedures, compatibility with other software, and general questions of the licensed services and products during and after installation. The self-service portal shall also facilitate status reporting (acceptance and socialization) of software problems, and provide downloads of software patches, fixes, and documentation.

The Contractor will provide quarterly reports on support requests (to include, user name, email address, Regional Area, location and description of the request). The Contractor will not authorize any software modifications or permissions changes. These requests are required to be forwarded to the Regional Area Point of Contacts (POC) and to include the HQ CMMS Coordinator.

The CMMS solution shall include Development, Test and Production systems, all of which are hosted as part of a FedRAMP service offering with a current FedRAMP Provisional Authorization.

The contractor shall clearly describe and distinguish the level of effort required to accredit the solution.

Operational Requirements This section contains free form questions and/or requirements for completion by the Contractor to ensure understanding of the operation of the proposed solution. The Contractor shall include an evaluation of all requirements as part of their proposal.

Operational Requirement

O1 The contractor shall define what product suite(s) are the products proposed part of

Name suite(s) and describe how functionality/modules are structured.

O2

The contractor shall describe the established framework for customizing the product

Please describe how you distinguish between customization and configuration of the product(s) proposed.

O3 The contractor shall describe how upgrades and new releases are managed and deployed to minimize impact and disruption to customers.

O4

The contractor shall establish the level of effort in hours required by internal IHS support staff as well as skills required to maintain and operate the solution post implementation. This should include analysts, administrators, and owners. In response to this requirement the contractor shall clearly distinguish these resources apart from the resources required to implement the solution.

O5 The contractor shall specify the solution support organization locations, hours/days of operation and the level of support provided.

O6 The contractor shall define service level agreements, response time, and commitments are available for each support level.

O7 Service Level Agreements (SLA) will provide performance, backup information, support requests (results, frequency, etc), and any useful information to provide better processes for IHS.

O8 The contactor shall enable the ability of the solution to support single sign on.

O9

The contractor shall define the licensing and ongoing support/maintenance costs, as well as estimates for implementation (including installation, initial training, configuration of systems, deployment, ongoing support for future implementations, etc.).

O10 The contractor shall provide process, procedures and supporting documents which will be provided to IHS to operate and maintain the system.

Functional Requirements The Contractor shall propose their approach in fulfilling the functional requirements listed below. The Contractor shall include an evaluation of all requirements as part of their proposal. The Contractor’s evaluation responses shall be limited to one of the below statements for each requirement (comments may be provided):

5 - Requirement is met by out of the box, no configuration or customization needed ("just add data").

4 - Requirement is met with additional configuration of existing structures, using built-in administrator's tools.

3 - Requirement is met with additional customization, e.g. adding tables, building customized reports, building custom workflow.

2 - Requirement is met by the use of a separate module or third-party product. Not included in core product.

1 - Requirement is met by software that is currently under development, has not been installed at a single client site, or in Beta test

0 - Requirement is not met.

Service Desk Management

Requirements

F1 Support for after call closure capabilities such as performing automatic follow-up on specific date/time via visual or sound notification

F2 Support for automated escalation capabilities such as automatically calculating the total cost to the customer associated with an incident or service request (from total time spent, hourly rates, cost of parts, etc.

F3 Support for cutting and pasting text, embedding html, bitmaps, screenshots, attachments etc. List any other types of functionalities such as drag and drop.

F4 Ability to translate time zones to local times for active ticket timestamps and for reporting analytics

F5 Automated matching rules for Incidents, Problems, Known Errors, and Workarounds, based on categorization or Configuration Item rules

F6 Ability to report on the number of contacts (calls, emails, web requests) received.

F7 Ability to report the percentage of repeat contacts for the same Incident (e.g., status, inquiry)

F8 Ability to report the number of Incidents escalated hierarchically and functionally.

F9 Ability to provide a suggestion box capability for customers and users to submit feedback.

Knowledge Management

Requirements

F10 Full feature knowledgebase search capability, such as full text, keyword and catalog content

F11 Automatic use of description to search knowledgebase

F12 Ability to support integration or link with prebuilt knowledgebase or external Web-crawling capability that allows our KM to find content on other sites

F13 Ability to search categorized/indexed documents or Frequently Asked Questions (FAQs) based on a symptom driven menu

F14 Ability to search previously resolved tickets and integration with Incident and Problem Management (e.g. ability to propose solution based on key words within incident or problem record)

F15 System to highlight which Frequently Asked Questions (FAQs) are needed based on top searched or clicked articles

F16 Ability to publish globally as well as to a specified audience based on their role.

Articles viewable by assigned Support Groups

F17 Support for unique identifiers for individual knowledge articles/documents and ability to differentiate between different versions

F18 Articles should include created and last edited dates as properties of the document.

Does the tool automate the population of Knowledge Records with author and owner data, creation date, as well as any other attributes required by the organization?

F19 Ability to provide usage metrics to report on who is using the knowledge articles and the platform being used to access them

F20 Ability to receive user driven feedback to determine usefulness of a knowledge article

F21 Ability to provide knowledge management capabilities by floating the most relevant results to the top in order of closest match to search. Explain administrative abilities to manage the relevancy rules/weightings.

F22 Ability to provide knowledge management support capabilities by allowing the service desk agent/user to launch another parallel search

F23 Ability to provide knowledge management support capabilities by matching against known errors.

F24 Ability to provide knowledge management support capabilities by providing a list of open problems

F25 Ability to manage full lifecycle of knowledge articles through administration capabilities (e.g., submission, review, approval, publishing, usage monitoring, etc.).

Please explain capabilities.

F26 Ability to nominate the contents of an Incident for inclusion into the Knowledge Base and report on the number of Incidents nominated

F27 Ability to launch fast knowledge searches using the categorization (or partial categorization) selections as key value search parameters.

F28 Ability to combine multiple sources of knowledge objects. List the number of sources and how they can be integrated into the knowledge base.

F29 Ability to create a knowledge article via a fill-in-the-blank form or allow for knowledge approvers to quickly publish a knowledge article.

F30 Ability to automatically populate a knowledge article into an Incident.

F31 Ability to support technical-facing knowledge articles, i.e., a technical role can access either technical-facing or customer-facing articles.

F32 Ability to support searching within search results list

F33 Does the tool track how often a Knowledge Record is accessed or used?

F34 Search & Retrieve

Does the tool enable the search and retrieval of data by various search terms? E.g.:

the ability to search by subject, owner or date.

F35 Out of Date Records

Can the tool record, delete or archive out of date, duplicate, inaccurate or unwanted information?

F36 Does the tool show the comparative relevance or importance of the information during a search? E.g.: most helpful, etc.

F37 Does the tool facilitate searching of content that is stored in multiple formats?

Request Fulfillment

Requirements

F38 Ability to facilitate the creation, modification, fulfillment and closure of Service Request records based on a business process workflow supported by approval and implementation tasks

F39 Provide the requestor with an entitlement-based view of the services they are authorized to request

F40 Ability to automatically relate the records such as a task created from a single Service Request

F41 Ability to save the contents of a partially created Service Request at any time. Does your tool have a pre-defined lifecycle, ability to copy existing request or clone?

Provide Detailed explanation.

F42 How does the product support notifying end-user of the fulfillment and verifying their satisfaction with the Service request fulfillment?

F43 Ability to graphically configure workflow to enable parallel and sequential tasks within a request activity

Incident Management

Requirements

F44 Ability to identify an issue as a service request versus an incident in the same screen.

F45 Ability to support Impact, Urgency and Priority assignment guidance from categorization, number of children tickets, etc.

F46 Ability for Email intake to create tickets automatically based on parsing information and routing to Service Desk(s), including the ability for all email communication to be added to the journal entry/ticket notes to build history and knowledge.

F47

Ability to integrate with automatic monitoring tools to allow for system alerts to automatically create, open, assign, and update existing Incidents. List the monitoring tools that are certified for integration in the comments section. Provide detailed explanation.

F48 Ability to issue communications / alerts / notifications based on Priority and Support Team group rules that include business hour / after hour rules

F49 Ability to configure various Email, phone, text and other notifications based on any field change (e.g., status changing from Incident open, to accepted, to resolved, etc.).

F50 Ability to automatically set the Urgency, Impact, Assignment Group(s), Notification and Escalation based on the categorization chosen.

Workflow & Reporting

Requirements

F51 Ability to create templates with pre-populated field and content for records used by facility and biomedical support teams (e.g., Change Models, Incident and Request templates, etc.)

F52 Ability for each facility and biomedical teams to manage and administer their own assignment group queues, routing and dispatch rules.

F53 Ability to refer to other tickets such as vendor case numbers or another ticketing system reference number within an Incident, Problem, Change, or Service Request

F54 Ability to set role and group-based permissions for reports and queries. Please explain typical segmentation of constituencies for reports in a multi-sourced environment. e.g. who can view the reports

F55 Ability to produce scheduled reports automatically based on a defined schedule and email to pre-determined recipients.

F56 Ability for each facility, biomedical, Area POC and HQ to create Dashboards that are configurable for status, common issues, and assignee.

System Discretion

Requirements

F57 Provide the ability to restrict access to portions of the infrastructure based on roles, locations or other user defined grouping.

F58

Administrators identified in the platform will have the ability to: 1.

Application Access/Account Creation

2. System Access Request with permissions

3. Create, Approve and Assign Work Orders/Maintenance Tasks

4. Assign Priority Levels

5. View and Create Reports

6. Report Modifications

7. View Financial Information

8. Lockout/Delete accounts for after 30 days if system is not accessed

9. Modify Warranty information

10. Procurement/Contract documentation

11. Change templates for Work Orders, Task Criteria

12. Import/Export Data

13. Data Validation

14. Add Attachments

F59

Regional Area POCs identified in the platform will have the ability to in their Areas:

1. System Access Request with permissions for their Areas

2. Create, Approve and Assign Work Orders/Maintenance Tasks

3. Assign Priority Levels

4. View and Create Reports

5. Report Modifications

6. View Financial Information

7. Lockout/Delete accounts for after 30 days if system is not accessed

8. Modify Warranty information

9. Procurement/Contract documentation

10. Change templates for Work Orders, Task Criteria

11. Import/Export Data

12. Data Validation

13. Add Attachments

F60

Managers identified in the platform will have the ability to in their Facilities:

1. System Access Request with permissions for their Facilities

2. Create, Approve and Assign Work Orders/Maintenance Tasks

3. Assign Priority Levels

4. View and Create Reports

5. Report Modifications

6. View Financial Information

7. Lockout/Delete accounts for after 30 days if system is not accessed

8. Modify Warranty information

9. Procurement/Contract documentation

10. Change templates for Work Orders, Task Criteria

11. Import/Export Data

12. Data Validation

13. Add Attachments

F61

Technicians identified in the platform will have the ability to in their Facilities:

1. Create, Approve and Assign Work Orders/Maintenance Tasks

2. Assign Priority Levels

3. View and Create Reports

4. Report Modifications

5. View Financial Information

6. Lockout/Delete accounts for after 30 days if system is not accessed

7. Modify Warranty information

8. Procurement/Contract documentation

9. Change templates for Work Orders, Task Criteria

10. Import/Export Data

11. Data Validation

12. Add Attachments

F62

All other users not identified as an Administrator, POC, Managers, or Technicians in the platform will have the ability to in their Facilities: (This includes other contractors/vendors that IHS has support contracts with)

1. System Access

2. View and create reports

3. Add Work Orders/Tasks information

4. Add Attachments

5. Close Work Orders/Tasks (Send to Supervisor for final approval - Optional per Area)

F63 The users of the System Administrator Group will consist of 2-5 individuals that will be provided by IHS upon contract award.

F64 The users of the Regional Area POCs will consist of up to 30 users from designated Regional Area offices. IHS will provide a list of individuals upon contract award, with the option to update the list as appropriate.

Usability & Accessibility

Requirements

F65

What mobile and tablet platforms are supported? Describe ability to support highly flexible routing of Incidents, Self-Service, Changes and Service Requests based on staff located across multiple sites, in operations control areas, and may vary depending on factors such as time of day, tiered service values, etc.

F66 Accessibility to persons with disabilities by conformance to Section 508 and WCAG

2.0 criteria.

F67 Web pages are completely accessible using keyboard navigation only, without the use of a mouse

F68 Text can be accessed using assistive technologies that provide audio output, highlighting, etc.

F69 Ability to provide a web-based surveying tool. Please explain administrative capabilities for setting sampling rules, survey design, and delivery of survey invitations (e.g., through html links in email, etc.)

F70 Does the tool provide an audit trail of all record changes? Can this be viewed online through the tool? (essentially the 5 W's: What, When, Where, Who, Why)

F71 Ability for the tool to capture simple customer satisfaction (single click rating, icon, etc.) and ability for Area POCs, facility manager, biomed, and HQ to see their results for review and performance.

Change & Configuration Management

Requirements

F72 Provides the capability to produce and distribute a projected service outage view or schedule that would be understandable from end-user / customer perspective.

F73 Ability to support different approval capabilities for sequential and parallel approval, peer review, and other approval types. Please explain different approval types.

F74 Ability to complete change approvals through email and tablet/wireless/mobile devices.

F75 Ability to set up program dashboards for program managers without consuming a license.

F76 Ability to setup Executive dashboards for leadership without consuming a license for governing body and HQ.

F77 A 'sandbox' or other test/training environment to be used to preview system/software updates, upgrades, patches, etc. prior to implementation on the 'live' or 'production' system. As well as providing an environment to train new users.

F78 Ability to do bulk or batch imports and updates within the system.

Describe how functionality/process are structured.

Facilities Functionality

Requirements

F79 Ability to have space and move management of AutoCad/Rivet drawings. Import from AutoCad, xml, html, pdf, xlsx, doc, docx, Rivet, and all Office versions after 2010.

F80 Ability to have bidirectional replication with AutoCad

F81 Provides sustainability for utilities, energy consumption, manage water usage, track waste. Real time reporting availability.

F82

Provide Capital Project Management for budget planning, permit tracking (to include, PCRA (Preconstruction Risk Assessment), ICRA (Infection Control Risk Assessment), above ceiling, confined space, etc.), cost reporting, Gantt charts, resource management, and return on investment (ROI).

F83 Ability to report on Environment of Care specifications and standards that IHS will provide.

F84 Ability to develop standard reports for Joint Commission, AAAHC, CMS, and any other accreditation bodies that IHS will describe.

F85 Ability to communicate with Open API with facility legacy systems (eg HVAC, building automation systems)

F86 Compatible with RFID/RTLS with multiple 3rd party vendors Provide a list of compatible vendors with working configurations.

F87 Ability to have Key Management functionality

Biomedical Functionality

Requirements

F88 Ability to develop standard reports for Joint Commission, AAAHC, CMS, and any other accreditation bodies that IHS will describe.

F89 Ability to communicate with Open API with biomedical devices and biomedical automated test devices (eg Medtester, Datrend, Fluke) Provide a list of functioning vendors and work flows describing the process.

F90 Compatible with RFID/RTLS with multiple 3rd party vendors.

Provide a list of compatible vendors with working configurations.

F91 Ability to incorporate medical device cybersecurity to extend into IT ServiceNow platform and threat vulnerabilities on medical devices

F92 Ability to communicate with ECRI and RASMAS

F93

Support multiple risk criteria/categories in determining an aggregated risk determination. For example being able to set the NFPA 99 category, determine the (modified) Fennigkoh-Smith number, determine/set the IT risk level, equipment category per CMS (LS, Critical, Non-critical), and other criteria, then aggregate all of those into a final risk level.

F94 FDA UDI Support and mapping

F95 Alternative Equipment Maintenance functionality

C3.1.2 Task 2 – Project Delivery Approach

Project Management The Contractor shall provide a Project Manager (PM) and Solutions Architect (SA) in support of providing both administrative and technical oversight for the duration of the project.

In addition, the Contractor shall provide a Subject Matter Expert (SME), who will assist with Risk Management Framework (RMF) documentation, and Assessment and Authorization activities.

The contractor’s PM shall have resources and authority to ensure efficient and timely program execution and shall be the focal point within the contractor's activity for all required program tasks. The PM shall be the primary contact through which communications, work assignments, and technical directions flow between the Government and the Contractor. The Contractor shall assign a designated representative to act in the absence of the PM. The PM, or designated representative shall provide technical and functional support required for the project management of this PWS including:

Quality Assurance Progress/status reporting Schedule development, integration, and status reporting Risk identification/handling/mitigation strategy Project Reviews

The contractor’s SA will provide technical guidance to IHS during the course of the project in the following four (4) key areas:

Technical Best Practices Architecture Oversight Technical Roadmap Technical Quality Assurance

Implementation Approach In support of implementation of the proposed system the Contractor shall propose deliverables of which align to the IHS CMMS implementation scope.

Implementation Requirements The contractor shall also provide a summary of the implementation strategy and professional services approach that you would recommend for IHS. This section contains free form questions for completion by the Contractor to ensure understanding of the implementation of the proposed solution. The Contractor shall include an evaluation of all requirements as part of their proposal. Respondents should base their proposal on the information provided in background material and any other typical implementation experiences/parameters from organizations with similar characteristics as IHS. Note that IHS has a low service management maturity currently but is interested in an appropriate strategy for installing, implementing, and receiving value from the new solution as an enabling part of the broader CMMS program.

Implementation Requirements

I1 Describe your recommended implementation approach for the waves:

Wave 1:

1) Vendor workshops with IHS Steering committee to design the work flow process prior to implementation. (This will include week long sessions with Biomed and Facilities held in Albuquerque until processes are tested and decided)

2) The initial Pilot Area will be decided during the workshops along with the order of implementation to the rest of the Areas.

3) The implementations will be done in week long sessions to start with Biomedical and then Facilities to follow. (To include training)

4) This wave will provide lessons learned during migration and implementation and training.

5) Implementation will not proceed to the next Area until the work is signed off by the Area POC and Area Facility Director.

Wave 2:

6) Will distinguish implementation and migration order of each Regional

Area.

7) Separate facility and biomedical module implementation and trainings

Future Wave Iterations:

8) IHS wants to create a repeatable rollout approach incrementally to subsequent Regional Areas.

I2

The contractor shall provide a high-level Gantt chart representation of recommended implementation plan showing expected timeline for the different activities required for implementation (e.g., software setup and rules configuration, testing, training, etc.

I3

The contractor shall provide their CMMS Processes targeted for deployment (i.e., Incident, Knowledge and Change Mgmt.) for simplicity and consistency and best practices. Please provide sample configuration decision workbooks / templates for these processes.

I4

The contractor shall provide a Project Plan to include the estimated effort, timing, knowledge, and resource role and responsibility requirements (in Level of Effort) from IHS administration/support for pilots as well as incremental waves of deployment to additional IHS Areas and Sites.

I5 Describe assets that will be available to IHS to accelerate the implementation.

This may include, but not be limited to, process diagrams, test scripts, and reports.

Provide samples of such assets.

I6 What quality assurance steps or gates do you include in your implementation methodology to check the status or health of the project?

I7 The contractor shall provide Administrator and Regional Area POC workshops for best practices and work flows. IHS will provide current work flows and processes.

I8 Describe your security approach to linking legacy systems to off-premise (e.g., SaaS, managed hosting) implementation environments.

I9 How much time does it take during typical implementation to complete the security validation and approval activities for the Cloud/SaaS model (for an organization such as IHS)?

C3.1.3 Task 3 – Training

Functional User Training (Train the Trainer Model) o Process User Training for Wave 1 & 2 Fulfillers of the platform supporting implementation processes.

o The Contractor shall include the necessary training credits or conference passes for IHS personnel to attend a training event which provides training opportunities for the entire CMMS Platform and which IHS personnel may attend sessions provided by industry and government agencies which have implemented the CMMS Platform from which IHS personnel may learn of lessons learned.

o The Contractor shall provide additional training hours for online, onsite, and conference attendance.

o Trainings for Area staff will be at the discretion of the Area POC. They will consist of onsite and online trainings.

C3.1.4 Task 4 – Licensing Renewal

Licensing Renewal Year 1 The contractor shall provide license renewals required for the first year of operation

The contractor shall provide renewal of solution licenses of which are valid for 12 months from the date the licenses are provided to IHS. The contractor is authorized to propose additional licenses to account for organizational growth, of which shall not exceed 10% of the total required license count provided within the PWS.

Active licenses shall be renewed at a prorated amount in an effort to align all license renewals on a common reoccurring basis.

Licensing shall include support from the SaaS vendor to include access to vendor support via a self-service portal and toll-free support line. Vendor support personnel will be available to assist in resolving software errors, answering questions regarding installation procedures, compatibility with other software, and general questions of the licensed services and products during and after installation. The self-service portal shall also facilitate status reporting (acceptance and socialization) of software problems, and provide downloads of software patches, fixes, and documentation.

Licensing Renewal Year 2 The contractor shall provide license renewals required for the second year of operation

The contractor shall provide renewal of solution licenses of which are valid for 12 months from the date the licenses are provided to IHS. The contractor is authorized to propose additional licenses to account for organizational growth, of which shall not exceed 10% of the total required license count provided within the PWS.

Active licenses shall be renewed at a prorated amount in an effort to align all license renewals on a common reoccurring basis.

Licensing shall include support from the SaaS vendor to include access to vendor support via a self-service portal and toll-free support line. Vendor support personnel will be available to assist in resolving software errors, answering questions regarding installation procedures, compatibility with other software, and general questions of the licensed services and products during and after installation. The self-service portal shall also facilitate status reporting (acceptance and socialization) of software problems, and provide downloads of software patches, fixes, and documentation.

Licensing Renewal Year 3 The contractor shall provide license renewals required for the third year of operation

The contractor shall provide renewal of solution licenses of which are valid for 12 months from the date the licenses are provided to IHS. The contractor is authorized to propose additional licenses to account for organizational growth, of which shall not exceed 10% of the total required license count provided within the PWS.

Active licenses shall be renewed at a prorated amount in an effort to align all license renewals on a common reoccurring basis.

Licensing shall include support from the SaaS vendor to include access to vendor support via a self-service portal and toll-free support line. Vendor support personnel will be available to assist in resolving software errors, answering questions regarding installation procedures, compatibility with other software, and general questions of the licensed services and products during and after installation. The self-service portal shall also facilitate status reporting (acceptance and socialization) of software problems, and provide downloads of software patches, fixes, and documentation.

Licensing Renewal Year 4 The contractor shall provide license renewals required for the third year of operation

The contractor shall provide renewal of solution licenses of which are valid for 12 months from the date the licenses are provided to IHS. The contractor is authorized to propose additional licenses to account for organizational growth, of which shall not exceed 10% of the total required license count provided within the PWS.

Active licenses shall be renewed at a prorated amount in an effort to align all license renewals on a common reoccurring basis.

Licensing shall include support from the SaaS vendor to include access to vendor support via a self-service portal and toll-free support line. Vendor support personnel will be available to assist in resolving software errors, answering questions regarding installation procedures, compatibility with other software, and general questions of the licensed services and products during and after installation. The self-service portal shall also facilitate status reporting (acceptance and socialization) of software problems, and provide downloads of software patches, fixes, and documentation.

C3.1.5 Task 5 – Project Assumptions

IHS acknowledges that the success of the Project and the provision of services and deliverables are fully dependent upon IHS’s timely participation and cooperation. The following assumptions are related to the project scope and IHS’s current business processes as of the effective date of this PWS. Deviations from these assumptions are expected to lead to commensurate changes in the timeline and fees, such changes shall be addressed in a Task Order modification or additional Task Order.

The following are general assumptions concerning this PWS:

IHS is responsible for providing the complete and correct definition and documentation of the business processes within scope for this Project and implementing all business process changes required to support the Project.

During the Project, the Contractor may apply updates containing fixes to relevant bugs. Additional updates and version upgrades are the responsibility of the Contractor after the Project is complete.

Updates and version upgrades are to have a 48 hour notification to IHS Administrators.

Contractor will notify IHS Administrators of when the maintenance will occur 1 hour before implementation and notification when completed.

IHS will not grant the Contractor resources local and/or administrative and remote access to IHS’s domain instances for the purposes of providing the Services. Contractor will be required to work with cleared IHS administrators to access instances.

IHS will provide appropriate work areas, including Internet access, for Contractor personnel when they are onsite. If Internet is not available for Contractor personnel, they will be notified prior to travel, so the Contract may coordinate possible alternative Internet access for Contractor personnel.

IHS will provide the required resources and ensure active participation. This will include, without limitation, an executive decision-maker, product / process owner(s), project leadership and management, subject matter experts and technical resources.

Multi language configuration is out of scope.

There is only one (1) production instance in scope to be shared by all IHS groups; and one (1) testing and training instance in scope to be shared with IHS groups.

Performance Analytics will be configured for usage and data collection for Change Management, Incident Management, Major Incident, and Knowledge Management, as determined during the Examine Stage workshops in this PWS in the production environment. The dashboard configurations will be performed at least 30-60 days after the initial go-live of technical capabilities in order to ensure accurate and robust data availability.

The Service Catalog items will not be altered, configured, adjusted or rewritten by the Contractor to accommodate Mobile configuration items. The alternation of client scripts to support Mobile views is out of scope; they will not be rewritten or altered during this deployment.

Contractor will not convert inactive data (Incident, Change, Request) from other systems (i.e.

legacy systems).

IHS reserves the option to convert inactive data at a later date at the discretion of the Areas. This option includes the ability to review archival data for reporting functionality.

Transactional data migration will only include active Incident and Change Management data.

IHS will supply communication and workshops with current vendor to collect all core data

(locations, department, user data, chart of accounts, CI) to be imported in a supported format (CSV, CSV (tab), Excel, XML, SQL, etc). Contractor will assist with normalization of data, but not be responsible for data modification, cleansing or alteration before, during or after importing data.

Contractor will customize any security concepts of the Contractor application while integrating with an API.

Contractor will not build any custom import processes.

C.4 PROJECT RESOURCING

IHS acknowledges that: (a) Contractor’s obligations relating to Project are conditioned and dependent upon IHS’s timely fulfillment of its responsibilities as set forth in this PWS; and (b) IHS’s failure to timely fulfill its responsibilities may result in additional fees and that any resulting delay in the Project or timelines shall not be attributable to Contractor. Any changes shall be addressed through a Task Order modification or additional Task Order

There is only one designated Key Personnel for this requirement, Project Manager. The contractor may otherwise replace or re-assign its personnel during the Project upon notification to IHS. The contractor does not have to guarantee that certain designated Contractor personnel will be assigned to IHS’s account.

Contractor may at any time subcontract any or all of its obligations hereunder to any third party or agent.

Contractor is solely responsible for the acts or omissions of subcontractors. In addition, Contractor is solely responsible for the payment of any compensation due or allegedly due to subcontractors, and subcontractors may not seek payment (either directly or indirectly) from IHS.

1.4.1 IHS Support Resources

The following table is a list of IHS Roles with a description of their responsibilities of which will be assigned to the project. The Contractor should expect one (1) IHS Resource may fulfill more than one role. If the contractor requires a dedicated resource for any role it shall be identified.

IHS Role Responsibilities

Project Manager The Project Manager is responsible for tracking and communicating project status, serving as an escalation point to resolve obstacles, and working to deliver project work on schedule and budget. The Project Manager works closely with the Contractor Project Manager and in coordination with all other involved resources to plan, manage, and deliver Contractor releases.

System Administrator(s)

The System Administrator is responsible for maintaining the stability and usability of the Contractor platform by performing application maintenance, managing support for incidents related to Contractor applications, and contributing to Contractor software releases by delivering configuration tasks and features. The Contractor System Administrator has sound technical ability that enables the fulfillment of common configuration and maintenance tasks.

Technical Resource(s)

The Technical Resources are responsible for assisting with the development of the Contractor application and integrations.

Process Owner(s) The Process Owners are responsible for the correct and complete definition of each of the processes implemented within the Contractor platform.

Product Owner(s) The Product Owners are responsible for ensuring that the Product Backlog is defined with Stories, visible, transparent, and clear to all, and shows what the Project Team will work on next. The Product Owner will also demonstrate the configured functionality to the IHS’s stakeholders at the end of each Sprint.

Subject Matter Experts (“SME”)

The SME is responsible to confirm the design to help meet IHS’s requirements, and to work with Contractor to identify opportunities for the processes to be moved into Contractor. The role may comprise of both functional and technical experts. The SME will also possess in-depth functional and technical understanding of any necessary processes and function.

Testing Coordinator Coordinates IHS Testing activities, including Test Plan, Test Cases and Test Execution

Quality Assurance Engineer

The Quality Assurance Engineer is responsible for validating the application functionality configured or customized by Platform Administrators and Contractor technical specialists.