SOW Automated High Density Pharmacy Storage and Inventory Solution (Draft).pdf

PDF 835 KB Posted

Attached to
Automated High Density Pharmacy Storage and Inventory Solution
Solicitation number
NIH-CC-20-002472
Issued by

About this file

This sources sought notice requests capability statements from potential offerors for a Research Hospital High Density Automated Pharmacy Storage and Inventory Solution to be provided to the National Institutes of Health Clinical Center. Key requirements for the solution include an automated robotic storage system capable of storing at least 60,000 line items, integration with the Allscripts EHR and Omnicell ADCs, automated bagging and labeling of patient medications, and inventory management software. Responses are due by January 3, 2020 and should address the offeror's ability to meet the technical requirements, company information, status as a small or large business, and ability to comply with limitations on subcontracting if a small business. The government will use the information for planning purposes only and will not award a contract based on the responses.

View the file

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

NIH CC Pharmacy

Statement of Work

Automated High Density Pharmacy Storage and Inventory Solution

NIH/ CC / PHARM

SOW: Automated High Density Pharmacy Storage and Inventory Solution

Table of Contents

PART 1 – GENERAL INFORMATION

PART 2 – MINIMUM REQUIREMENTS

PART 3 - GOVERNMENT FURNISHED PROPERTY, EQUIPMENT, AND SERVICES

PART 4 - CONTRACTOR FURNISHED ITEMS AND SERVICES

PART 5 – OTHER SYSTEM AND TECHNICAL SPECIFICATIONS

PART 6 – PROJECT MANAGEMENT, IMPLEMENTATION, SERVICE

PART 7 - APPLICABLE PUBLICATIONS

PART 8 - DEFINITIONS & ACRONYMS

Technical Exhibit 1 – Deliverables Schedule

Technical Exhibit 2 – Estimated Workload Data

Technical Exhibit 3 – CC Data Center

Technical Exhibit 4 – NIH CC EHR Clinical Research Informatics Information System (CRIS)

Technical Exhibit 5 – NIH CC EHR CRIS ADT Interface

Technical Exhibit 6 – CC Remote Access Options

PART 1 – GENERAL INFORMATION

The NIH CC Pharmacy department requires an Automated High Density Pharmacy Storage and Inventory Solution.

The system may be commercially available and will require 24 hour emergency service response capability from the contractor. Non-Developmental items and development items are not anticipated.

This Statement of Work (SOW) issued by National Institute of Health, Clinical Center describes the goals expected to be achieved with regard to executing the transition to an automated storage and inventory management system.

1.1 Introduction:

The National Institutes of Health (NIH), Clinical Center Department of Pharmacy is pursuing the acquisition of an automated storage device and inventory management software for the inpatient pharmacy and Investigational

Drug Management and Research Section (IDMRS). The primary goal of this acquisition is to provide the solution, services and training necessary for the Department of Pharmacy for ordering, sorting and distributing medications administered to the patients at the National Institutes of Health Clinical Center.

1.2 Background:

The National Institutes of Health (NIH), a part of the U.S. Department of Health and Human Services, is the primary federal agency for conducting and supporting medical research. Helping to lead the way toward important medical discoveries that improve people’s health and save lives, NIH scientists investigate ways to prevent disease as well as the causes, treatments, and even cures for common and rare diseases. Composed of 27 institutes and centers, the NIH provides leadership and financial support to researches in all fifty states and throughout the world.

The Clinical Center at the NIH in Bethesda, Maryland, is the nation’s largest hospital devoted to clinical research. It is a national resource that makes it possible to rapidly translate scientific observations and laboratory discoveries into new approaches for diagnosing, treating, and preventing disease. Approximately 1,500 studies are in progress at the NIH Clinical Center. About half the studies are the first tests of new medications or medical treatments in patients.

The CC Pharmacy employs approximately 45 inpatient and outpatient pharmacists and approximately 35 inpatient and outpatient pharmacy technicians. The inpatient section is further divided into Unit Dose (UD) and Intravenous

Admixture Unit (IVAU). The inpatient pharmacy is open 24 hours a day, seven days a week. The Unit Dose section of the Pharmacy Department dispenses, on average, 40,000 unit dose medications per month. The IVAU is responsible for the compounding of sterile injectable preparations.

1.3 Current Environment:

The Department of Pharmacy’s primary operating objective is to support and conduct research by providing safe, high quality care – one patient – one medication at a time. The secondary operating objective is standardize, improve effectiveness (service, outcomes), and reduce waste.

The NIH Clinical Center Pharmacy Department is structured around a hybrid medication distribution model including both cart fill and Automated Dispensing Cabinets (ADCs). A 24 hour cart-fill system is used in delivering scheduled medications in patient specific bins to Omnicell ADCs. Patient specific medication drawers are filled by technicians and checked by pharmacists prior to delivery. New and revised medication orders are reviewed and verified by pharmacists either in central pharmacy or by the clinical specialists. ADCs are located on patient care units and in clinics to facilitate access to as needed medications, stat antibiotics, controlled substances and some routine first doses. The ADC restock prints in central pharmacy and are filled manually from the central unit dose area and the controlled substance safe by a technician, and audited by a pharmacist. Technicians restock each ADC using a bar-coded restocking label.

The pharmacy has automated some of the dispensing phase of the medication-use process yet still maintains manual system for restocking ADCs, cart fill and managing medication inventory levels. In an effort to fully automate the dispensing and inventory phase of the Medication Use Process, there is a need to utilize a fully automated high density storage along with inventory management software to bridge the gaps identified.

The Clinical Center currently utilizes Allscripts Sunrise v16.3 as the primary Electronic Health Record (EHR) for

Prescriber Order Entry. The EHR is primarily managed by the Department of Clinical Research Informatics (DCRI).

1.4 Objectives: To acquire an automated pharmacy storage and inventory solution that will be integrated with the pharmacy clean room and interfaces with the ADCs, pharmacy inventory management systems, IV workflow solutions in order to increase the efficiency. The dispensing software will also communicate with the pharmacy information system to allow first-dose and cart-fill/ADC dispensing requests to be received and then processed and filled by technicians. The system will provide real time tracking of current inventory and medications to order.

1.5 Scope of Work

The contractor shall provide the applicable services in support of the required identified in the SOW.

The scope of the automated storage and inventory management system will apply to the following components of

Pharmacy Department

1.5.1 The Contractor shall be responsible for planning, installing, training, testing and continuous maintenance support of the automated storage and inventory management system.

1.5.2 The solution provided must be capable of managing all medications stored and dispensed by the department.

1.5.3 Training of pharmacy staff. (See Technical Exhibit 1)

1.5.4 Onsite implementation and support. (See Technical Exhibit 1)

1.5.5 The contractor shall provide a solution that will Interface with the current EHR, ADC and other COTS pharmacy systems to exchange medication and patient data.

1.6 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 equipment as the Department of Pharmacy Area expands.

The Period of Performance is estimated to begin sometime in February 2020 and run through February, 2025 if all options are exercised.

Estimated Periods of Performance is as follows.

Base Period: February 16, 2020 – January 31, 2021

Option Period One (1): February 1, 2021 through January 31, 2022

Option Period Two (2): February 1, 2022 through January 31, 2023

Option Period Three (3): February 1, 2023 through January 31, 2024

Option Period Four (4): February 1, 2024 through January 31, 2025

1.7 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:

New Year’s Day Memorial Day Columbus Day Christmas Day

Martin Luther King Day Independence Day Veterans Day

President's Day Labor Day Thanksgiving Day

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

1.8 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).

1.9 Installation Timing: The Contractor will work with the COR 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 a.m. and 7:00 p.m., Monday through Sunday, including holidays and any day declared an official Federal Holiday.

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

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

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

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

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

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

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

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

1.14 NIH CC Contracting Officer's Representative: The NIH CC COR is a specialist from the NIH CC Pharmacy 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: TBD

Address: 10 Center Drive, Building #10, Room 1C240. Bethesda, MD 20850

Email: TBD

Phone Number: TBD

1.15 NIH CC Automated Storage and Inventory Management Implementation Team: The NIH Technical Implementation Team includes the COR, Pharmacy Project Manager, Pharmacy Management, NIH CC IT staff, NIH CC Security staff.

1.16 Executive Management Oversight: Executive Management oversight for this project is provided by the NIH CC Chief Pharmacy and the NIH CIO.

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

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

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

1.20 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 – MINIMUM REQUIREMENTS

2.1 The Contractor shall provide a non-developmental automated robotic Storage System capable of storing high density medications that will operate as a single integrated solution. The solution shall use a commercial off the shelf software and hardware component that are configurable to the NIH Clinical Center workflow. The solution must have been demonstrated and proven to be in use at another inpatient pharmacy hospital setting.

2.2 The contractor shall provide a dedicated on-site support staff member that will provide service, troubleshooting and training for up to a year post implementation.

2.3 The solution shall fit into the pharmacy. Any changes needed/required to accommodate the vendors quoted solution such as the relocation of current fixed shelving/furniture in existing space or addition of dedicated power lines, must be quoted as part of vendors solution and will be considered normal installation. Vendors are responsible for verifying all dimensions and other design features necessary for operation and installation of their quoted solution.

2.4 The solution shall be a fully automated dispensing and inventory management system utilizing a robotic arm for picking and storage.

2.5 The hardware component shall be capable of withstanding a 60 second loss of utility power with no loss of data and no manual intervention to recover.

2.6 The automated storage system shall be able to store at minimum 60,000 line items of non-IV formulary.

2.7 The system shall be able to dispense medications for verified patient orders including scheduled, STAT/Now and first dose orders.

2.8 The system must include a barcode-driven checking/verification utility that can be used by pharmacists (or technicians tech-check-tech) to verify accuracy of orders before leaving the pharmacy.

2.9 The pharmacy automation solution shall use automatic wireless barcode scanning as a means of medication and patient validation throughout the stocking, filling, dispensing and returning to stock process.

2.10 The solution shall support both non-IV and non-narcotic formulary in variety of form factors such as oral solids in unit dose (manufacturer-packaged blister style or pouch/repackaged), oral solid cards, vials (1- 100 mL), liquid dose cups, syringes/capujects, packets, patches, boxes, and IV bags up to 150 mL).

2.11 The solution shall be capable of automatically bagging patient specific medications by placing dispensed medications into sealed bags printed with patient or cabinet information with barcode.

2.12 The system shall be capable of ensuring that earliest expiring medications are dispensed first.

2.13 The system shall have an active storage management system for maximum efficiency and throughput.

2.14 The pharmacy automation solution shall interface with the Allscripts EHR, Omnicell ADCs, inventory Management System and other commercial off-the-shelf (COTS) pharmacy systems. Loss of the interface with EHR shall not impede the system from continuing to fill orders until all orders that have already been transferred are completed.

2.15 When dispensing medication from the storage unit, the pharmacy automated storage solution shall

2.15.1 Be capable of using and displaying multiple unique patient identifiers.

2.15.2 Print a label to be affixed to the medications to be restocked in the ADC.

2.15.3 Use software to fill products not in the automated storage, including, but not limited to fluid bags and irregular dosage forms.

2.15.4 Automatically notify user if the automation does not have enough quantity to fulfill the entire order and provide the user option to replenish the automation or divert the order to manual fulfillment based on defined par, max, min and critical levels.

2.16 Upon receiving information from CRIS or ADC, the pharmacy automation System shall:

2.16.1 Be capable of using and displaying multiple unique patient identifiers.

2.16.2 Be capable of updating patient location and handle patient merges automatically in real time.

2.16.3 Process the information received and retrieve the medication stored.

2.16.4 Alert pharmacy personnel of stat vs routine orders.

2.16.5 Print medication labels that can be used for restocking.

2.17 For manually fulfilled orders, the system shall require user to scan the medication package before providing the label.

2.18 The system shall allow users to flag an order when there is insufficient quantity to fulfill the entire ordered quantity.

2.19 The solution shall have the ability to recognize brand name NDC (National Drug Code) and generic NDC items found on the FDA approved NDC directory.

2.20 The inventory management software shall provide “Real-Time” inventory tracking of pharmaceutical products.

2.21 The system shall be capable of providing historical reference of all items in the event of a recall.

2.22 The inventory management software shall support manual or automated cycle counts.

2.23 The system shall be capable of ordering via the web for remote locations.

PART 3 - GOVERNMENT FURNISHED PROPERTY, EQUIPMENT, AND SERVICES

3. GOVERNMENT FURNISHED ITEMS AND SERVICES:

The government will be responsible for:

A. Rack Space in NIH CC Data Center.

1. Support Operating System of any Required Server.

2. Provide Virtual Server(s) if the system can be virtualized.

3. Perform Monthly OS Patches.

4. Provide 2012 or greater MS SQL Server Enterprise License. MS SQL 2014/2016 preferred. Plan for migration within one year accepted. All databases must be encrypted.

5. Provide Network to the NIH Data Center.

B. Providing necessary network and LAN drops for the equipment in the central pharmacy.

C. Server Maintenance (See paragraph 5.6)

1. NIH CC will manage the OS, Patches, MS SQL 2012 Database or greater for the Physical Computer.

D. Formulary Size

1. Formulary Items

a) UD Room Temperature – 1200

b) UD Refrigerated – 200

c) UD Frozen – 30

2. Non Formulary Items

a) UD Room Temperature – 100

b) UD Refrigerated – 100

3. Investigational

a) Room Temp Caps/Tabs – 1500

4. Daily Dispensing Volume

a) % Cartfill vs % Cartless – 70% vs 30%

b) Number of cartfill doses dispensed per day – 400

c) Number of first doses/stats dispensed per day – 60

5. Average daily census – 114

6. Wholesaler – Amerisource Bergen

PART 4 - CONTRACTOR FURNISHED ITEMS AND SERVICES

4. CONTRACTOR FURNISHED ITEMS AND RESPONSIBILITIES:

The Contractor shall provide:

A. Hardware and equipment not limited to physical automated storage device, printers, barcode scanners, monitors and backup battery supply to support up to 2000 line items.

B. Servers if the system cannot be virtualized.

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

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

E. All parking in accordance with NIH requirements.

F. Specifications required of the virtualized server, if applicable. 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.

G. MS SQL 2014/2016 preferred with plan to migrate within one year.

PART 5 – OTHER SYSTEM AND TECHNICAL SPECIFICATIONS

5.1 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).

5.2 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. Responder 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.

5.3 Construction and Wiring of the Solution

5.3.1 All vendor hardware wiring shall abide by the existing NIH/CIT Cable Standards and Guidelines (http://orf.od.nih.gov/PoliciesAndGuidelines/BiomedicalandAnimalResearchFacilitiesDesi gnPoliciesandGuidelines/Pages/DesignRequirementsManualPDF.aspx ). This also includes any new infrastructure that is required for this installation.

5.3.2 The Contractor is responsible for reviewing the plans for construction and wiring and must receive approval from the NIH CC COR before any work starts on an area by area basis.

5.3.3 The Contractor must utilize existing pathways (i.e. conduits, cable tray) before installing new pathways between existing individual rooms or between any of the system components.

5.3.4 The Contractor will use green cables for all Network Cables for automated storage networking components.

5.3.5 The Contractor is responsible to ensure that all accountable government property, i.e.

computer, computer displays, and servers, shall be delivered to the pharmacy procurement office at NIH Building 10 Room 1C-166.

5.3.6 The Contractor shall report all discrepancies noted that are not within the scope of this agreement to the NIH CC COR and the NIH CC Contracting Officer.

5.3.7 The Contractor is responsible to get any repair or replacement of components not within the scope of this agreement, which will result in additional cost approved by the NIH CC Contracting Officer prior to procurement of the component and installation.

5.3.8 NIH ORF policies and guidelines for pathway and infrastructure requirements must be followed and can be found at:

http://orf.od.nih.gov/PoliciesAndGuidelines/BiomedicalandAnimalResearchFacilitiesDesi gnPoliciesandGuidelines/Pages/DesignRequirementsManualPDF.aspx

5.3.9 The Contractor shall provide and install all necessary wiring cables, conduit and backboxes.

5.3.10 The Contractor shall maintain record drawings of all installed components and associated wiring on building plans and provide these drawing on the completion of each unit to the

NIH CC COR.

5.4 EHR ADT Interface

5.4.1 The automated storage system shall support an HL7 ADT from the NIH CC Clinical Research Information System (CRIS).

http://orf.od.nih.gov/PoliciesAndGuidelines/BiomedicalandAnimalResearchFacilitiesDesignPoliciesandGuidelines/Pages/DesignRequirementsManualPDF.aspx http://orf.od.nih.gov/PoliciesAndGuidelines/BiomedicalandAnimalResearchFacilitiesDesignPoliciesandGuidelines/Pages/DesignRequirementsManualPDF.aspx http://orf.od.nih.gov/PoliciesAndGuidelines/BiomedicalandAnimalResearchFacilitiesDesignPoliciesandGuidelines/Pages/DesignRequirementsManualPDF.aspx http://orf.od.nih.gov/PoliciesAndGuidelines/BiomedicalandAnimalResearchFacilitiesDesignPoliciesandGuidelines/Pages/DesignRequirementsManualPDF.aspx

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

A. Ability for the data to be unidirectional from CRIS.

B. Ability to handle location updates and patient merges.

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

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

E. The automated storage system interface will send a positive or negative message acknowledgement for each received message.

5.4.3 The automated storage system shall store and display patient demographics.

5.4.4 The automated storage system shall store and display the visit reason which is the protocol study number as part of patient demographics. The format for the field is ##-[A- Z][A-Z]-####. Examples are 17-C-0234, 99-AG-0024.

5.5 EHR Order Interface

5.5.1 The automated storage system shall support an HL7 Medication Order Management Interface from the NIH CC Clinical Research Information System (CRIS).

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

A. Ability for the data to be unidirectional from CRIS.

B. Mapping of standard ORM/RDE segment field components and subcomponents fields to be determined.

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

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

5.5.3 The automated storage system shall store and display order information by patient, priority and dispense date/time.

5.5.4 The automated storage system shall store and display the protocol study number of the order as part of order information received in the order interface. The format of the field is ##-[A-Z][A-Z]-####. Examples are 17-C-0234, 99-AG-0024.

5.6 Server Specifications. These requirements are for any workstation or hardware provided to support the automated storage and inventory management system, such as the Data Analytics Component.

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

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

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

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

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

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

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

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

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

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

5.6.11 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, ForeScout, CA Asset Management Agent, CylancePROTECT Agent, Nessus Agent, VMWare Tools (virtual only), NetBackup Agent (physical only), EMC PowerPath (physical, SAN connected hosts only).

5.6.12 The Server/Application Infrastructure shall provide end-to-end encryption for data in transit in accordance with HHS Standard for Encryption of Computing Devices and Information (if web based the system must use SSL and be located behind the CC DMZ).

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

5.6.14 The Server/Application shall provide comprehensive system performance measurement tools and reports to allow continual monitoring and optimization of performance.

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

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

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

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

5.6.19 The Server/Database Management System (RDBMS) Infrastructure must be MS SQL 2012 enterprise or greater. MS SQL 2014 is preferred with plan to migrate to MS SQL 2014/2016.

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

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

5.6.22 The Server/RDBMS Infrastructure configuration shall support encryption in accordance 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

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

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

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

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

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

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

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

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

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

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

5.7 Application Specifications. These requirements are for any application that is accessible via NIH Workstations such as System Configuration, System Administration, automated storage, inventory management and Data Analytics.

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

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

5.7.3 Any application administration module that will require a full client must be provided via CITRIX XenApp 6.5 (current) and 7.12 (planned).

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

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

5.7.6 Applications shall not be dependent on browser specific controls.

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

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

5.7.9 Applications shall provide a help file index.

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

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

5.8 NIH Network Security/User Access Requirements.

5.8.1 The System shall require NIH Single Sign On/Active Directory for access.

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

5.8.3 The System shall provide restricted access to functions and patients based upon user class.

5.8.4 The System shall always display the current user name.

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

5.8.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).

5.8.7 The System shall require the use of a card reader and the NIH Smartcard for authentication.

5.8.8 The System shall monitor multiple failed attempts to logon by triggering a system alert.

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

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

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

5.8.12 The System shall provide the ability to set up and manage user access and privileges using role-based security. Security Roles, at a minimum,

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

5.8.14 The System shall provide the ability to assign/restrict rights/privileges to the security roles. Security Rights, at a minimum, A. ability to search for patient information B. ability to add new users to the system C. ability to change users’ roles and privileges D. ability to create reports, data analytic dashboards E. ability to run specific reports F. ability to view specific data analytic dashboards G. ability configure reports and dashboards and assign to specific roles

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

5.8.15 The System shall log user sessions.

5.8.16 The System shall log access to patient data.

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

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

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

5.8.19 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/) :

A. A certificate that meets the guidance below:

Publicly validated TLS certificates, either from HHS or a public vendor for publicly facing websites. Internal sites are allowed to use HHS certificates. Self-signed certificates are prohibited from use.

TLS certificate uses SHA2 as a signature algorithm.

TLS certificate key length of at least 2048 bits.

Use of wildcards is strongly discouraged.

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

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

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

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

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

G. 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:

HIGH and CRITICAL Vulnerabilities: 30 days

Medium Vulnerabilities: 45 days

LOW Vulnerabilities: 60 days.

H. 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).

PART 6 – PROJECT MANAGEMENT, IMPLEMENTATION, SERVICE

6.1 PROJECT MANAGEMENT

6.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 key personnel by the government: Contract Manager, Contractor Project Manager, and Contractor Systems Engineer.

6.1.2 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 key personnel by the government: Contract Manager, Contractor Project Manager, and Contractor Systems Engineer.

6.1.3 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

6.1.4 The Contractor shall use Microsoft Project for providing a project plan to the NIH CC COR throughout the project deployment and across each task.

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

6.1.6 The Contractor shall follow project management and project change management as part of the project implementation.

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

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

6.2 TRAINING

6.2.1 The Contractor shall provide a Training Plan that encompasses all requirements proposed in the 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 on the automated storage and inventory management system.

6.2.2 Schedule for training sessions shall be coordinated with the COR.

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

6.2.4 The Contractor shall provide at least six (6) training sessions.

6.2.5 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

6.2.6 The Contractor shall provide training materials to include quick reference guide(s) in addition to full documentation describing installation, support and troubleshooting steps.

6.2.7 The Contractor shall schedule on-site or virtual training prior to installation to be completed within two (2) weeks prior to installing the first items of the automated storage and inventory management system.

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

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

6.3 SERVICE LEVEL MANAGEMENT AND SUPPORT SYSTEMS

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

6.3.2 All repairs must meet equipment manufacturers’ specifications.

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

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

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

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

6.3.7 The Contractor shall have an on-site response time based on the table below:

Problem Severity Respond to Call

Fix Problem Remotely

On Site Problem Resolution

Warranty Issue related to component 1 hour Within 2 hours of problem determination

Resolve issue within 4 hours of problem determination.

Production System Problem – patient safety at risk, one or more unit down, production system down or major portions unusable

1 hour Within 2 hours of problem determination

Resolve issue within 4 hours of problem determination.

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

1 hour Within 2 hours of problem determination

Determine plan within 4 hours. Resolve issue within 6 hours of problem determination.

Production System Problem – system usable with manual workaround

1 hour Within 2 hours of problem determination

Determine plan within 4 hours. Resolve issue within 6 hours of problem determination.

Total System Down 1 hour Within 2 hours of problem determination

Determine plan within 4 hours. Resolve issue within 6 hours of problem determination.

Non-production System Problem 4 hours Within 24 hours of maintenance call

Within 48 hours of maintenance call.

6.4 HARDWARE INSTALLATION AND TESTING

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

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

6.4.3 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 COTR. Testing must be completed and accepted by NIH after Delivery Acceptance and prior to end user training by Unit. (See Technical Exhibit 1)

6.5 AUTOMATED STORAGE AND INVENTOTY SYSTEM ACCEPTANCE

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

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

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

6.6 WARRANTY

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

6.6.2 The Contractor shall provide manufacturer five (5) year warranty for the automated storage system parts effective upon acceptance.

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

6.7 SYSTEM RETIREMENT

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

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

6.7.3 The Contractor shall provide a way for the government to easily view the data in the event of system retirement.

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 Automated Storage and Inventory Management System, including:

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.

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

Conform to NFPA 70.

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

REFERENCES

o Comprehensive Accreditation Manual for Hospitals ( www.jointcommission.org ) o Guidelines for the Design and Construction of Hospitals and Outpatient Facilities, The Facility Guide Institute, 2014 edition ( www.fgiguidelines.org ) o Underwriter’s Laboratories UL-1069 current release (http://www.ul.com ) o NFPA – National Fire Protection Association (National…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .