COMBINED SYNOPSIS Nursing.docx

COMBINED SYNOPSIS/SOLICITATION FOR COMMERCIAL ITEMS

General Information

Original Response Date: March 23, 2020

Contracting Office Address Office of Purchasing and Contracts 6707 Democracy Boulevard Suite 106 Bethesda, MD 20892 Description This is a combined synopsis/solicitation for commercial items prepared in accordance with the format in Federal Acquisition Regulation (FAR) subpart 12.6, “Streamlined Procedures for Evaluation and Solicitation for Commercial Items,” as supplemented with additional information included in this notice. This announcement constitutes the only solicitation; being requested, and a written solicitation document will not be issued.

This solicitation is a Request for Quotation. The solicitation document and incorporated provisions and clauses are those in effect through Federal Acquisition Circular 2020-04, dated 01-15-2020.

Background

NIH Clinical Center The National Institutes of Health (NIH) Clinical Center is a 200-bed research hospital. The Clinical Center supports nearly 50% of all NIH funded general clinical research center beds in the nation, as well as over 25% of outpatient visits. In supporting approximately 1,600 active clinical research protocols, the Clinical Center admits patients from around the country and the world who participate in experimental treatments and studies at no charge.

The vision of the Clinical Center is to serve as the nation’s premier research hospital for conducting clinical research to improve the health of human kind. It also serves as a national resource for clinical research by developing diagnostic and therapeutic interventions, enhancing systems to ensure the safe, efficient, and ethical conduct of clinical research, training clinical researchers, and leading the response to the nation’s public health needs.

In 2005, the Mark O. Hatfield Clinical Research Center was opened. The state of the art facility is home to new inpatient units, day hospitals and research labs and connects to the existing Warren Grant Magnuson Clinical Center, which opened its doors to patients in 1953. Together, the Magnuson and Hatfield centers form the NIH Clinical Center, the world's largest clinical research complex, serving a dual role: providing humane and healing patient care, and an environment for clinical researchers to advance clinical science.

The Clinical Center provides the NIH intramural researchers and limited extramural collaborators with physical infrastructure and medical expertise to perform groundbreaking and innovative clinical research. Of the 1,600 research protocols, approximately half are natural history studies, especially rare diseases, and the other half are mostly clinical trials, predominantly Phase I and Phase II, often first-in-human to test safety and efficacy and often are the first tests of new drugs and therapies.

The majority of visits (e.g. inpatient admissions or outpatient visits) are planned. Patients and guardians may be authorized to receive transportation to and from NIH, local hospitals, hotels, local airports, and residences. Some of the local hospitals that NIH partners with for services are: Walter Reed National Military Medical Center, Washington Hospital Center, Johns Hopkins Suburban Hospital and Children’s National Medical Center. Some of these patients may also require transport of oxygen, etc. which is also arranged upon request. The term patient will be used to refer to research protocol participants throughout this document.

2. SCOPE OF WORK

0. Current Environment:

The primary operating objective of the Clinical Center Nursing Department of is to support and conduct research by providing safe, high quality care. The secondary operating objective is standardize, improve effectiveness (service, outcomes), and reduce waste.

The Clinical Center Nursing Department consists of approximately 722.5 FTEs, 3 Day Hospitals, over 19 outpatient clinics, and approximately 14 inpatient units, all supporting the biomedical research.

A nursing self-scheduling and productivity system would greatly improve efficiency and productivity. In addition, these types of systems allow management to monitor and stay within budgetary parameters. This type of system would improve proficiency and indirectly improve patient care throughout the entire Clinical Center facility, as well as enhance nursing satisfaction and retention.

0. Objectives:

To purchase and install a nursing self-scheduling and productivity system that can be used for the Clinical Center Nursing Department

0. Scope of Work The contractor shall provide hardware, software, services for the procurement, implementation and support of a nursing self-scheduling and productivity system.

2. The Contractor shall provide the nursing self- scheduling and productivity system that will operate as a single integrated solution.

2. The solution shall be commercial off the shelf software and hardware components that are configurable to the NIH Clinical Center workflow.

2. The solution must have been demonstrated and proven to be in used at another inpatient hospital and clinical systems setting.

2. The vendor shall provide customer support following the options in the Appendix: REMOTE SUPPORT.

2. A Memorandum of Understanding (MOU) with NIH CC Security Team and Maintenance Contract must be completed for any REMOTE SUPPORT Agreement.

0. Contract Type and Period of Performance A single Firm Fixed Price type contract is contemplated for one 12-month base period and four 12-month option periods to extend the effective period of performance. Options to increase quantities may be exercised by formal modification to the contract should there be a need to provide additional.

Estimated Periods of Performance is as follows.

Base Period: 06/1/2020– 5/31/2020 Option Period One (1): 6/1/2021 – 5/31/2021 Option Period Two (2): 6/1/2022 - 5/31/2022 Option Period Three (3): 6/1/2023 - 5/31/2023 Option Period Four (4): 6/1/2024 – 5/31/2024

0. Recognized Holidays: Work may occur on Federal Holidays. Maintenance Support may occur all hours and across all days.

The ten holidays observed by the Federal Government are as follows:

Also, any other day declared by the President of the United States to be a National or Federal holiday.

0. Hours of Operation: The NIH CC operates 365 days per year, 24 hours per day including all holidays. Maintenance Support must be provided across all days and hours (365x24x7).

0. Installation Timing: The Contractor will work with the nursing self-scheduling and productivity system Implementation Team to schedule and perform the installation. Installation will be performed at the convenience of the location receiving the system. Installation may occur between the hours of 9:00 AM EST and 7:00 PM EST., Monday through Sunday, including holidays and any day declared an official Federal Holiday.

0. Place of Performance: The work to be performed under this contract will be performed at the NIH Clinical Center Nursing Department, 9000 Rockville Pike, Building 10, Bethesda, MD 20892.

0. Security Requirements: Contractor personnel performing work under this contract must have a NIH CC Contractor badge which will require fingerprinting and a background check.

0. Physical Security: The Contractor shall be responsible for safeguarding all government equipment, information and property provided for contractor use. At the close of each work period, government facilities, equipment, and materials shall be secured.

0. Key Control: The Contractor shall establish and- implement methods of making sure all keys/key cards issued to the Contractor by the Government are not lost or misplaced and are not used by unauthorized persons. NOTE: All references to keys include key cards. No keys issued to the Contractor by the Government shall be duplicated. The Contractor shall develop procedures covering key control that shall be included in the Quality Control Plan. Such procedures shall include turn-in of any issued keys by personnel who no longer require access to locked areas. The Contractor shall immediately report any occurrences of lost or duplicate keys/key cards to the NIH CC Contracting Officer.

0. In the event keys, other than master keys, are lost or duplicated, the Contractor shall, upon direction of the NIH CC Contracting Officer, re-key or replace the affected lock or locks; however, the Government, at its option, may replace the affected lock or locks or perform re-keying. When the replacement of locks or re-keying is performed by the Government, the total cost of re-keying or the replacement of the lock or locks shall be deducted from the monthly payment due the Contractor. In the event a master key is lost or duplicated, all locks and keys for that system shall be replaced by the Government and the total cost deducted from the monthly payment due the Contractor.

0. The Contractor shall prohibit the use of Government issued keys/key cards by any persons other than the Contractor’s employees. The Contractor shall prohibit the opening of locked areas by Contractor employees to permit entrance of persons other than Contractor employees engaged in the performance of assigned work in those areas, or personnel authorized entrance by the NIH CC Contracting Officer.

0. Special Qualifications: The Contractor must ensure that all staff maintain his/her NIH badge which requires completion of annual training (i.e., security, privacy, fire safety, Joint Commission).

0. Post Award Conference/Periodic Progress Meetings: The Contractor agrees to attend any post award conference convened by the contracting activity or contract administration office in accordance with Federal Acquisition Regulation Subpart 42.5. The NIH CC Contracting Officer, NIH CC Contracting Officers Representative (COR), and other Government personnel, as appropriate, may meet periodically with the contractor to review the contractor's performance. At these meetings, the NIH CC Contracting Officer will apprise the contractor of how the government views the contractor's performance and the contractor will apprise the Government of problems, if any, being experienced. Appropriate action shall be taken to resolve outstanding issues. These meetings shall be at no additional cost to the government.

0. NIH CC Contracting Officer's Representative: The NIH CC COR is a specialist from the NIH CC Nursing Department whose role is to define, plan, track and manage the project.

The following individual is designated as the NIH CC COR:

Project Officer Name: Kathleen N. Carpenter Address: 10 Center Drive, Building #10, Room 1C240. Bethesda, MD 20850 Email: Kathleen.carpenter@nih.gov Phone Number: (301) 594-0477

0. NIH CC Implementation Team: The NIH Technical Implementation Team includes the COR, Kathleen Carpenter, Project Manager, Clinical Center Nursing Department Management, NIH CC IT staff, NIH CC Security staff.

0. Executive Management Oversight: Executive Management oversight for this project is provided by the NIH CC Chief for the Nursing Department, Gwen Wallen and the NIH CC CIO.

Identification of Contractor Employees: All contract personnel attending meetings, answering Government telephones, and working in other situations where their contractor status is not obvious to third parties are required to identify themselves as such to avoid creating an impression in the minds of members of the public that they are Government officials. They must also ensure that all documents or reports produced by contractors are suitably marked as contractor products or that contractor participation is appropriately disclosed. Badges must be worn at all times.

Data Rights: The Government has unlimited rights to all documents/materials produced under this contract. All documents and materials, to include the source codes of any software, produced under this contract shall be Government owned and are the property of the Government with all rights and privileges of ownership/copyright belonging exclusively to the Government. These documents and materials may not be used or sold by the contractor without written permission from the NIH CC Contracting Officer. All materials supplied to the Government shall be the sole property of the Government and may not be used for any other purpose. This right does not abrogate any other Government rights.

Organizational Conflict of Interest: Contractor and subcontractor personnel performing work under this contract may receive, have access to or participate in the development of proprietary or source selection information (e.g., cost or pricing information, budget information or analyses, specifications or work statements, etc.) or perform evaluation services which may create a current or subsequent Organizational Conflict of Interests (OCI) as defined in FAR Subpart 9.5. The Contractor shall notify the NIH CC Contracting Officer immediately whenever it becomes aware that such access or participation may result in any actual or potential OCI and shall promptly submit a plan to the NIH CC Contracting Officer to avoid or mitigate any such OCI. The Contractor’s mitigation plan will be determined to be acceptable solely at the discretion of the NIH CC Contracting Officer and in the event the NIH CC Contracting Officer unilaterally determines that any such OCI cannot be satisfactorily avoided or mitigated, the NIH CC Contracting Officer may affect other remedies as he or she deems necessary, including prohibiting the Contractor from participation in subsequent contracted requirements which may be affected by the OCI.

Phase Out Period: To reduce any decreases in productivity and to prevent possible negative impacts on additional services, the Contractor shall have personnel on board for 60 days prior to the contract phase out period. During the phase out period, the Contractor shall transfer any system knowledge to the Government.

PART 2 – FUNCTIONAL REQUIREMENTS

2.1 System Assignments:

The system shall:

0. Must be able to develop our own customized reports, at no extra charge, without going through the company from any data point/field within the system.

0. Must be able to export reports into excel, HTML, and PDF formats; and have the capability to manipulate data in Excel

0. Must be able to provide all direct (productive) and indirect (non-productive) hours for any personnel in the Clinical Center Nursing Department at the Department, Division, Cost Center and Individual level

0. Must be able to calculate turnover and transfer rates annually, monthly, weekly, and daily

0. Must have unlimited Skill Codes for identification of groups of employees

0. Must have simplistic self-scheduling system to include the following:

1. Minimum and maximum staffing requirements

1. Ability to balance the schedule

1. Ability to swap shifts

1. Ability to float personnel

1. Ability to see skill mix of personnel

1. Ability to see when core numbers are met or not met

1. Ability to have organizational scheduling rules (i.e. RN for RN swaps; overtime alerts; etc.)

1. Ability for individual units to set specific scheduling parameters defined by their scheduling committee.

1. Ability to access scheduling system outside NIH campus (i.e. home or mobile device)

1. Ability to send direct communication via email or text to staff regarding staffing needs for the day, credentialing expiration, etc.

0. Must have the ability to perform an audit trial on who entered and/or subtracted data from the system (event logs), and have the ability to run these logs at any time

0. Must have the ability to send reports directly from the system in an e-mail to the requestor

0. Must be able to provide learning materials (i.e. videos, manuals, help screens, and remote assistance when needed)

0. Must develop onboarding materials of the system, and provide direct onsite support during implementation.

0. Must develop direct support during system upgrades, and communicate any new system requirements/upgrades of the system to system administrator.

0. Should have 24 hour customer service support line accessible to end users, and respond to system critical issues

2.1 Evaluation Criteria:

1. Must develop onboarding materials of the system, and provide direct onsite support during implementation.

1. Must develop direct support during system upgrades, and communicate any new system requirements/upgrades of the system to system administrator.

1. Minimum and Maximum Staffing Requirements

1. Ability to Balance the Schedule

1. Ability to Swap Shifts

1. Ability to Float Personnel

1. Ability to see when Core Numbers are or are not met

1. Ability to see Skill Mix

1. Ability to have general organization scheduling rules

1. Ability for individual units to set specific scheduling parameters

1. Ability to access scheduling system outside NIH campus (i.e. home or mobile device)

1. Ability to send direct communication via email or text to staff regarding staffing needs for the day, credentialing expiration, etc.

1. Annually

1. Monthly

1. Weekly

1. Daily

PART 3 - GOVERNMENT FURNISHED PROPERTY, EQUIPMENT, AND SERVICES

3. GOVERNMENT FURNISHED ITEMS AND SERVICES:

The government will be responsible for:

1. Rack Space in NIH CC Data Center.

0. Provide Microsoft Server 2016 or greater MS OS.

0. Data at rest (hardware, file level) encryption of the Server.

0. Provide Virtual Server(s) image files if the system can be virtualized.

0. Perform Monthly OS Patches.

0. Provide 2016 SP1or greater MS SQL Server Enterprise License. Any and all databases must be encrypted.

1. Server Maintenance (See section 5)

1. NIH CC DCRI will manage the OS, Patches, MS SQL 20XX Database or greater for the Physical and Virtual Computer.

PART 4 - CONTRACTOR FURNISHED ITEMS AND SERVICES

1. CONTRACTOR FURNISHED ITEMS AND RESPONSIBILITIES:

The Contractor shall provide:

0. Servers if the system cannot be virtualized.

0. All the software required to operate and manage the robotic delivery system.

0. Master list of all hardware and software components including length of warranty and average life of the solution. See Table 8.3.

0. Master list of Software Maintenance Agreements and License Agreements for all software.

0. Specifications required of the virtualized server, if applicable.

0. All parking in accordance with NIH requirements.

PART 5 – OTHER SYSTEM AND TECHNICAL SPECIFICATIONS

0. Authentication: The solution shall support integration with NIH directory services supporting an integrated authentication and authorization model (single sign on) utilizing the e-Government profile for Security Assertion Markup Language 2.0 (SAML 2.0).

0. Confidentiality, Security, and Privacy: All patient data shall be stored on the server hosted on the premises at the National Institute of Health, Clinical Center. Contractor personnel shall adhere to the Privacy Act, Title 5 of the U.S. Code, Section 552a and applicable agency rules and regulations. The Contractor will work with NIH CC Security Team for all FISMA/SAA documentation.

0. If the applications is replacing an existing system:

2. The contractor shall provide a document with data dictionary mapping between the existing and new database. The mapping shall include but not limited to, table-to-table and column-to-column mapping. The contractor shall provide migration plan for existing data and highlight the all the data elements that will be excluded in the migration.

2. The contractor shall provide migration plan for existing data and highlight all the data elements that will be excluded in the migration.

0. Server Specifications. These requirements are for any workstation or hardware provided to support the nursing self-scheduling and productivity system.

0. The Contractor shall provide detailed specifications for installation and configuration of all hardware components including virtualization, web services and database requirements. Actual installation and configuration of servers in government furnished computer racks will be performed by Contractor.

4. The Contractor will identify any and all licensing requirements for hardware, software, number of users, number of concurrent users, etc.

4. The Server/Database/Application Infrastructure must be supported to run on Windows Server 2012 R2, at a minimum. Windows Server 2016 is preferred but a plan to migrate to Windows Server 2016 within one year is acceptable.

4. The Server/Database/Application Infrastructure shall be updated monthly for security patches for vulnerabilities identified as critical, high or medium.

4. The Server/Application Infrastructure shall provide comprehensive tools for managing both client and server software configurations that minimize hands-on involvement of DCRI technical staff.

4. The Server/Application Infrastructure shall provide comprehensive security and confidentially features including, but not limited to, biometric, password suppression, audit capabilities required by HIPAA, FISMA, and the Privacy Act, and ability to restrict or require data fields.

4. The Server/Application Infrastructure shall include redundancy for any servers required for the system. Servers should be configured in a high availability configuration and be clustered. Servers can be setup as virtual in the NIH CC Virtual Environment.

4. The Server/Application Infrastructure shall support FIPS 140-2 validated encryption at rest for all servers to support the Integrated System. This includes file systems and databases.

4. The Server/Application Infrastructure may support virtual servers on VMWare vSphere 6 as part of the NIH CC Virtual Environment.

4. The Server/Application Infrastructure configuration of hardware will comply with NIH standards for security hardening and install the NIH toolset of required applications, which will be performed by NIH.

4. The Server/Application Infrastructure will require multiple agents on each Server. These agents include but are not limited to: McAfee VirusScan 8.8 (Patch 8), FireEye, BigFix, ForeScout, CylancePROTECT Agent, Nagios, Nessus Agent, VMWare Tools (virtual only), NetBackup Agent (physical only), EMC PowerPath (physical, SAN connected hosts only).

4. The Server/Application Infrastructure shall provide end-to-end data in transit encryption (if web based the system must use SSL and be located behind the CC DMZ). The Server/Application Infrastructure shall provide data encryption of data at rest at both the hardware (if physical) and file level.

4. The Server/Application Infrastructure shall provide tools for notifying system administrators in the event of slowness.

4. The Server/Application Infrastructure shall provide tools for notifying system administrators in the event of system down.

4. The Server/Application Infrastructure shall provide the ability to monitor and record data storage device usage.

4. The Server/Application Infrastructure shall provide tools for automated updating of client software.

4. The Server/Database Management System (RDBMS) Infrastructure must be MicroSoft (MS) SQL 2014 or greater. The latest version of MS SQL is preferred.

4. The Server/Application/RDBMS must only utilize supported products. Unsupported hardware, software, operation systems, applications and database management system versions must be replaced one (1) year prior to end of life.

4. The Server/RDBMS Infrastructure configuration shall support mirroring with at least two nodes with the always on feature turned on.

4. The Server/RDBMS Infrastructure configuration shall support encryption with HHS Standard for Encryption of Computing Devices and Information. All encryption solutions used throughout the Department and referenced throughout this document must be Federal Information Processing Standard (FIPS) 140-2 validated.

4. The Server/RDBMS Infrastructure shall support both complete and incremental backup of database and system files. Backups shall be able to be performed with the system up or down and shall not require taking the system down.

4. The Server/RDBMS Infrastructure shall provide the capability for exporting of system files to allow system restore capabilities.

4. The Server/RDBMS Infrastructure shall provide a fail over capability so that the application will resume operations in the event of server failure.

4. The Server/RDBMS Infrastructure failover capabilities will not require human intervention.

4. The Server/RDBMS Infrastructure failover procedures will not require changes in client configuration such as server TCP/IP addresses.

4. The Server/RDBMS Infrastructure shall provide the ability to recover the database from backups and transaction logs.

4. The Server/RDBMS Infrastructure shall provide tools for monitoring and enhancing system performance and load distribution across servers.

4. The Server/Application/RDBMS Infrastructure shall provide tools for automated setup of client software so that software can be installed without Information Technology staff involvement at each client workstation.

4. The Server/Application/RDBMS Infrastructure shall provide version control for server software.

4. The Server/Application/RDBMS Infrastructure shall provide version control for structure changes in the database

0. Application Specifications. These requirements are for any application that is accessible via NIH Workstations such as System Configuration, System Administration, end user dashboard, etc.

5. Applications shall have a consistent look and feel across modules and functions.

5. Applications shall be designed to utilize at least 1024x768 resolution when applicable.

5. Any application administration module that will require a full client must be provided via CITRIX XenApp 7.15 LTSR.

5. Applications shall work across Windows 10, Mac OS platforms and CITRIX to include 32-bit and 64-bit platforms.

5. Applications shall support the following browsers: MS IE 11, MS Edge; Google Chrome, Safari 12 and most current for MAC; and FireFox with the most current of each Internet Browser within 3 months of release.

5. Applications shall not be dependent on browser specific controls.

5. Applications shall allow CC Administrators to set time-out duration based on organizational policy.

5. Applications shall provide the capability to exit with one keystroke or mouse-click after appropriate warnings have been acknowledged.

5. Applications shall provide a help file index.

5. Applications shall provide the ability for NIH to customize electronic help files.

5. All points of login into the application should allow a customizable warning banner. This includes websites, mobile and desktop applications/software.

5. The Server/Application Infrastructure shall provide end-to-end data in transit encryption (if web based the system must use SSL and be located behind the CC DMZ).

5. The Server/Application Infrastructure shall provide data encryption of data at rest at both the hardware (if physical) and file level.

0. NIH Network Security/User Access Requirements.

6. The web application shall require NIH Single Sign On/Active Directory for access.

6. All applications shall display the NIH/HHS warning banner and provide ‘ACCEPT’ and ‘DECLINE’ buttons. If DECLINE is selected, the application shall terminate. The contents of warning message shall not be hard-coded into the application; instead, it is read from a

6. database table or from web configuration file so there is the flexibility to update the message as and when needed.

6. The System shall provide the capability to automatically log users off after a specified period of inactivity using parameters that can be set by the system administrator.

6. The System shall provide restricted access to functions based upon user class.

6. The System shall always display the current user name.

6. The System shall require ID & non-displaying password.

6. The System shall have an access model that accommodates a variety of secure access methods, including, but not limited to, biometric or token-based access, and different access procedures for devices located inside the NIH intranet).

6. The System shall monitor multiple failed attempts to logon by triggering a system alert. The alert shall include date, time, user, ip address of user.

6. The System shall monitor multiple (i.e., 3) failed attempts to logon by disabling the login id.

6. The System shall connect/link/access with NIH active directory or NED Database to load all eligible employees into the system initially and to maintain the user list as employees come on board and leave.

6. The System shall allow CC staff to assign privileges to individual users of the system.

6. The System shall provide the ability to set up and manage user access and privileges using role-based security. Security Roles, at a minimum, to include read-only, application administrator, configuration access, application user.

6. The System shall allow CC staff to assign security rights, with the possibility of further customization based on individual need, to assign a group of privileges to any user based on their role or on organizational need.

6. The System shall provide the ability to assign/restrict rights/privileges to the security roles. Security Rights, at a minimum,

14. ability to add new users to the system

14. ability to change users’ roles and privileges

14. ability to create reports, data analytic dashboards

14. ability to run specific reports

14. ability to view specific data analytic dashboards

14. ability configure reports and dashboards and assign to specific roles

14. Ability to configure pathways, screens, choice lists selections.

6. The System shall log user sessions.

6. The System shall maintain an audit capability that will log access or modification of individual patient records viewed on reports.

6. The System shall log system events (i.e., add an event, issue a report request).

6. The System event field displays shall include event date and time.

6. If the System has any web components to include web sites or web services, the following HTTPS requirements must be met (refer to https://https.cio.gov/) :

0. A certificate that meets the guidance below:

0. Websites used only internal to the NIH network may use either HHS Certificate Authority (CA) or a public vendor CA

0. Websites accessed from outside the NIH must use a publicly trusted CA where the security trust can be verified for publicly facing websites

0. Self-signed certificates are prohibited from use, exceptions must be documented and approved.

0. TLS certificates use Secure Hash Standard (SHS) (FIPS PUB 180-4) SHA2 as a signature algorithm with the largest bit hash both client and server can support.

0. Digital signature certificates TLS certificate key length of at least 2048 bits.

1. TLS certificates cannot be issued for greater than 2 years without a documented exception.

0. Use of wildcards is strongly discouraged in favor of using subject alternative names.

0. Use of Subject Alternative Name (SAN) be used with permission if the function is required by the website or application

0. Deprecated encryption algorithms: protocols, ciphers and hashes should be removed or disabled. An example is TLS v1.0, SSL v1, v2, v3, RC4, Triple DES.

0. HTTPS Only: Only HTTPS shall be utilized for all websites and web services. The use of HTTP is prohibited.

0. Mixed Content: All content shall be served and referenced over HTTPS. Linking to libraries, CSS, JS, fonts, iframes, etc. that load content not hosted on the server shall be served over HTTPS.

0. HTTP Strict Transport Security (HSTS): HSTS shall be enabled for any and all System web servers.

0. Perfect Forward Secrecy shall be enabled on all web servers.

0. The use of weak or deprecated ciphers shall not be used.

0. The NIH shall perform a web application vulnerability scan of any websites using the IBM AppScan commercial product. The vendor is responsible for remediating any vulnerabilities identified within the following timeframe:

6. HIGH and CRITICAL Vulnerabilities: 30 days

6. MODERATE/MEDIUM Vulnerabilities: 45 days

6. LOW Vulnerabilities: 60 days.

0. The System shall ensure that the web site and servers are not vulnerable to the risks identified in the Open Web Application Security Project (OWASP) Top 10 list of web vulnerabilities (refer to www.owasp.org).

0. Administrative Access:

Administrative access to the system, system configuration, dashboard display and analytics must be available via NIH PC Desktop.

Administrative Access shall be available via NIH Network PC, Thin Client (using CITRIX) and CITRIX environments. PC Display is 27”.

Administrative Access shall allow the addition of users.

Administrative Access shall be restricted by role.

Administrative Access shall provide support for simultaneous use with no restriction to the number of users.

Administrative Access shall be capable to assign/change staff roles and rights.

0. Data Extractions The system shall allow the ability to extract data from the system to other systems either through MS SQL Extractions, API or developed scripts.

The system shall allow the ability to attach reporting systems such as MS SQL Reporting Services or Crystal Reports against the database.

The system shall allow the ability to attach dashboard systems such as Microstrategy, SAS, Tableau.

The system shall allow the creation or replication of an external data mart if access from other systems would affect performance.

0. Data Analytics and Reporting Component The Data Analytics and Reporting Component shall provide role based access to limit users access.

The Data Analytics and Reporting Component shall provide support for an unrestricted number of concurrent users to access report generation.

The Data Analytics and Reporting Component shall provide multiple standard reports including Summarized Call Statistics, Hourly Call Statistics, Detailed Patient Activity, Summary Patient Activity, System-Wide Activity, Current Staff Assignment, and Staff Assignment History.

The Data Analytics and Reporting Component shall provide the ability to generate the reports in real-time.

The Data Analytics and Reporting Component shall provide the ability to generate reports by response time, number of calls, reason for calls, work flow data.

The Data Analytics and Reporting Component shall provide the ability to generate reports based on time between request and response to request and resolution of request and provide the capability to allow research sensitive data collection.

The Data Analytics and Reporting Component shall allow reporting by month, quester, year, year to date for comparisons.

The Data Analytics and Reporting Component shall support exporting of data in tab delimited and .CSV and .PDF formats.

The Data Analytics and Reporting Component shall support commercial reporting tools that connect to the proposed database.

The Data Analytics and Reporting Component shall allow the ability to provide data to the NIH CC Reporting components.

The Data Analytics and Reporting Component shall provide a queryable database that provides logging of all call activity and staff response across the entire Patient Call Network.

The Data Analytics and Reporting Component shall provide report generation capability from any networked PC work station on the NIH LAN.

The Data Analytics and Reporting Component shall provide the ability to automatically email predefined reports at reoccurring periods. The time periods can be configured for a specific time every day, day of the week, every other week, or monthly. The reports will automatically update the data to “roll” with the reoccurring time periods when the reports are emailed.

0. EHR ADT Interface The system shall support an HL7 ADT Interface from the NIH CC Clinical Research Information System (CRIS).

The system shall include an HL7 compliant interface (V2.2 – 2.5) to receive relevant patient information from the ADT system with the following functionality:

0. Ability for the data to be bidirectional from CRIS to the server.

0. Mapping of standard ADT segment field components and subcomponents fields to be determined.

0. All updates shall be real time, but the server Interface Engine shall buffer data for any interruption of service.

0. The system will send a positive or negative message acknowledgement for each received message.

0. The system shall allow interface messages to allow the automatic merge of patients at the patient and visit level.

The system shall store and display patient demographics.

The system shall allow the ability to map Organizational defined fields such as protocol number which The system shall allow the backload of patient demographics.

The system shall allow the ability to map Organizational defined fields such as protocol number which is currently NN-CC-NNNN.

0. EHR Order Interface The system shall support an HL7 Order Management Interface from the NIH CC Clinical Research Information System (CRIS).

The system shall include an HL7 compliant interface (V2.2 – 2.5) to receive relevant medication order information from the EHR system with the following functionality:

0. Ability for the data to be bidirectional from CRIS to the server.

0. Mapping of standard ORM, RXC, ZPM, RXF or RXE segment field components and subcomponents fields to be determined.

0. All updates shall be real time, but the Interface Engine shall buffer data for any interruption of service.

0. The System will send a positive or negative message acknowledgement for each received message.

The system shall store and display order information by patient (MRN, Name, DOB), priority and transaction date/time.

The system shall allow the ability to map Organizational defined fields such as protocol number which is currently NN-CC-NNNN.

0. EHR Result Interface for Results:

The system shall support sending an HL7 ORU Interface to the NIH CC Clinical Research Information System (CRIS).

The system shall include an HL7 compliant interface (V2.2 – 2.4) to send relevant status and result information to CRIS.

0. Mapping of standard ORU segment field components and subcomponents fields to be determined.

0. All updates shall be real time, but the system Interface Engine shall buffer data for any interruption of service.

The system will show abnormal flags received with any result.

PART 6 – PROJECT MANAGEMENT, IMPLEMENTATION, SERVICE

6.1 PROJECT MANAGEMENT

1.

1.

The Contractor shall identify each key personnel to be assigned to this contract and a detailed resume shall be submitted for each key person proposed. The following personnel are considered as key personnel by the government: Contract Manager, Contractor Project Manager, and Pharmacist consultant.

The Contractor shall identify all prime and subcontractor(s), management and implementation personnel to be assigned to this project and describe their credentials, roles, responsibilities, and relationships to the contract and its implementation The Contractor shall use Microsoft Project or similar tools for providing a project plan to the NIH CC COR throughout the project deployment and across each task.

The Contractor shall provide a detailed draft plan with the proposal. (see technical questionnaire and exhibit table 1) The plan shall establish the budget, resource needs, major tasks and schedule for implementation required in accordance with American National Standards Institute/Electronic Industries Alliance (ANSI/EIA) Standard 748-A, Earned Value Management Standards, May 1998. The NIH CC and the Contractor will finalize the details such as specific dates and resources after award. The NIH CC and the Contractor will maintain the plan throughout the duration of the implementation work with regular updates provided by the Contractor.

The Contractor shall follow standard NIH CC project management and project change management procedures as part of the project implementation.

The Contractor shall submit the deliverables based on the content and timeframe identified under Technical Exhibit 1 – Deliverables Schedule.

The Contractor shall validate the Technical Exhibit 2 – Estimated Workload Data as part of the proposal.

The Contractor shall provide an on-demand report of hours spent and work performed to the NIH CC project manager. The report may be required on a scheduled basis for any contract that has a limited number of Contractor hours.

The Contractor shall provide technical and project manager resource time to participate in any required meetings (typically 1 to 2 hours per week) scheduled by the NIH CC for the duration of the project, including status meetings, demonstrations, training, testing, issue resolution, and lessons learned.

The Contractor shall provide live support for the final production implementation according to a detailed implementation plan, agreed to by the contractor and NIH CC. Support staff shall include any necessary technical resources, as well as the contractor’s project manager(s). Any resources that may be scheduled to participate in the final activation should also participate in any scheduled checklist reviews, mock activations, or rehearsals.

1. TRAINING

The Contractor shall provide a Training Plan that encompasses all requirements proposed in the Statement of Work (SOW). The plan shall be submitted with the Contractor proposal for consideration when making an award. Acceptance of training completion will be performed by the COR. Training is complete when the NIH CC Staff are capable and competent to independently perform all required work specific to their role using the system.

Schedule for training sessions shall be coordinated with the COR.

The Contractor shall train all staff members on the use of the system.

The Contractor shall provide at least five (10) training sessions.

The Contractor shall provide training that will include a period of live demonstration and observation of the staff using the system in each training session The Contractor shall provide training materials to include quick reference guide(s) in addition to full documentation describing installation, support and troubleshooting steps.

The Contractor shall schedule on-site or virtual training prior to installation to be completed within two (2) weeks prior to installing the first robot.

The Contractor shall provide training agendas, schedules, presentations, manuals and reference guides to the NIH CC COR prior to conducting any training.

The Contractor shall provide electronic training materials (e.g., CD-ROM, LMS and/or ongoing access to role specific computer based training) which shall also be accessible by staff unavailable to attend in person training, staff in need of refresher training or staff who are hired after the Contractor led initial training sessions.

1. SERVICE LEVEL MANAGEMENT AND SUPPORT SYSTEMS

The Contractor shall provide service management including routine and emergent service. The NIH CC COR will determine the need for service and evaluate emergent and urgent conditions.

All repairs must meet equipment manufacturers’ specifications.

The Contractor shall provide manufacturer trained staff and train certified CC employees as factory trained technicians to be first responders for unscheduled service calls.

The Contractor shall supply all parts and labor required to resolve issues. No refurbished equipment will be accepted. In the event that only a refurbished device is available the Contract Manager must notify and gain approval by the NIH CC COR.

The Contractor shall replace devices with new devices if the existing device is found defective, broken or after two (2) events were called regarding the device within one week. No refurbished equipment will be accepted. In the event that only a refurbished device is available the Contract Manager must notify and gain approval by the NIH CC COR.

The Contractor will certify monthly OS Security Updates to all MS Window Server and System Devices as needed.

The Contractor shall have an on-site response time based on the table below or provide response time and accepted by COR prior to implementation:

Production System Problem – major portions of system usable and mission critical workload can continue

1. HARDWARE AND SOFTWARE INSTALLATION AND TESTING

Acceptance and integration testing for all components shall be completed and accepted by NIH prior to deployment.

Software Acceptance Testing - Installation of application software and third party tools designed for System Administration and Data Analytics must be completed and accepted by NIH prior to the activation.

System Readiness Testing – System readiness testing includes detailed test plans for unit and integration testing for all proposed applications and system management tools for each defined phase. The Test Plan shall include installation, certification for use, acceptance testing and ready for go-live tests for functional and infrastructure requirements. Operational test shall include performance testing for throughput, response time, reliability and security. The Test Plan shall include methodology to provide the results of all testing done under this procurement in a format acceptable to the NIH CC COR. Testing must be completed and accepted by NIH after Delivery Acceptance and prior to end user training by Unit. (See Technical Exhibit 1)

1. SYSTEM ACCEPTANCE

The Contractor will work with the NIH CC COR for acceptance of the System.

The Contractor will provide that each component will have a 15 day system acceptance period following go live.

The Contractor will work with the NIH CC COR for acceptance of Individual Components.

WARRANTY

The Contractor shall warrant all non-system parts, labor and installation for a desired period of one (1) year effective upon task acceptance.

The Contractor shall provide manufacturer five (5) year warranty for the robot Management parts effective upon acceptance.

The Contractor shall provide the warranty which shall include all necessary software upgrades to keep the system fully operational while in use.

1. SYSTEM RETIREMENT

The Contractor shall provide a mechanism to export data from all components in which data exists to the government with the understanding that the governments owns all data entered into the system.

The Contractor shall provide a data dictionary to understand the data being provided to the government.

The Contractor shall provide a way for the government to view the data in the event of system retirement on a government server via a client, website or created report.

PART 7 - APPLICABLE PUBLICATIONS

APPLICABLE PUBLICATIONS (CURRENT EDITIONS) The Contractor must abide by all applicable regulations, publications, manuals, and local policies and procedures. The Contractor must provide components, material and labor that meet all applicable regulatory requirements for a hospital autonomous System, including:

1. Electrical Components, Devices, and Accessories: Listed and labeled according to UL1069 as defined in NFPA 70, Article 100, by a testing agency acceptable to authorities having jurisdiction, and marked for intended use.

1. Comply with NEC as applicable to construction and installation of system components and wiring.

1. Conform to NFPA 70.

1. Conform to HIPAA regulations relating to all patient communications including but not limited to text messaging, paging and public address systems.

REFERENCES

3. Comprehensive Accreditation Manual for Hospitals ( www.jointcommission.org )

3. NFPA – National Fire Protection Association (National Electrical Code NFPA 70 and 99) (http://www.nfpa.org/codes-and-standards)

3. ADA – Americans with Disabilities Act (http://www.ada.gov)

3. NEMA – National Electrical Manufacturers Association – Installation Standards (http://www.nema.org

3. U.S. Dept. of Labor / Occupational Safety and Health Administration (http://www.osha.gov)

3. Canadian Standards Association (http://www.csagroup.org)

PART 8 - DEFINITIONS & ACRONYMS

0.…