PWS RFI AITC_March 2024.docx

RTLS Server Sustainment Support at the Austin Information Technology Center

VA-24-000052401

RTLS SERVER SUSTAINMENT SUPPORT

AUSTIN INFORMATION TECHNOLOGY CENTER (AITC)

PERFORMANCE WORK STATEMENT (PWS)

DEPARTMENT OF VETERANS AFFAIRS

Veterans Health Administration Office of Healthcare Technology Management Real Time Location System (RTLS)

RTLS Server Sustainment Support At the Austin Information Technology Center

Date: March 15, 2024

VA-24-00052401

Contents

BACKGROUND

The mission of the Department of Veterans Affairs (VA), Veterans Health Administration (VHA) is to honor America’s Veterans by providing exceptional health care that improves their health and well-being. This care is delivered by engaged, collaborative teams in an integrated environment that supports learning, discovery and continuous improvement. The Office of Healthcare Technology Management, Real Time Location System (RTLS) Program Office helps to achieve this mission by deploying RTLS technology and enabling VA facilities to realize benefits to standardized operations and improved decision-making capabilities; in due course providing an enriched patient care environment for Veterans.

VHA’s RTLS is made up of several software and hardware components geared towards workplace efficiency. Commercially, RTLS generally refers to active tracking of assets/objects or people. Within VA, however, RTLS is an umbrella term that describes a variety of applications, a broader bundling of capabilities of which asset tracking (active, passive, and barcodes) is only one. The others are defined below. This bundling is largely the result of the Health Care Efficiency Major Initiative, the Facility Automation sub-initiative, initiated in 2010 under then-VA-Secretary Shinseki. Many applications that would contribute to healthcare efficiency were bundled under the RTLS rubric and referred to as “RTLS use cases.” These applications were acquired and continue to be acquired to help improve efficiency, reduce costs, and improve patient outcomes. The active use cases that were deployed under the VA national Indefinite Delivery, Indefinite Quantity (ID/IQ) acquisition are listed below.

1. Asset Tracking (AT) – Tracking assets for ad hoc searches, inventory, or loss prevention.

2. Cardiac Catheterization Lab (Cath Lab (CL)) – Supply chain management of high-value consumables within the Cath Lab.

3. Sterile Processing Workflow (SPW) – Standardization of sterile processing for surgical instruments and flexible endoscopes.

4. Temperature Monitoring (TM) – Automation of temperature monitoring for refrigerators and freezers where drugs, vaccines, and specimens are stored in a tightly temperature-controlled environment.

These four use cases are provided by four loosely integrated software packages: Infor for Asset Tracking and Temperature Monitoring, Wavemark for Cath Lab, CensiTrac for Sterile Processing, and CenTrak for the location engine. The location engine leverages the asset tracking infrastructure, which includes Wi-Fi access points, infrared and low frequency monitors. All the applications use an Enterprise Service Bus that allows them to communicate with one another and through interfaces to external VA systems.

VA contracted for and implemented an integrated, enterprise-wide solution for RTLS to support VHA. VA has a virtualized software configuration that consolidates the number of virtual servers required to run the backend (non-facility level) RTLS servers. This part of the RTLS solution is currently housed in the Austin Information Technology Center (AITC) and referred to in this task order (TO) as RTLS National Data Center (NDC), with the goal of consolidating additional servers in current and future deployments. This location also has an VA AITC RTLS Project Manager (PM) responsible for the servers that house the software.

SYSTEM ARCHITECTURE OVERVIEW

The RTLS architecture is divided into two groupings: components in VA Medical Centers (VAMC) and components in the NDC. Additionally, there are external interfaces that touch other VA systems. The scope of this TO includes all RTLS components located in the NDC for all Veterans Integrated Service Networks (VISNs) specified in Table 1 below, along with communications destined for external interfaces or inbound on those same interfaces. The scope depicted by location is shown in Figure 1. The RTLS component groupings at the VAMC and at the NDC are interdependent; as such, operations and maintenance efforts are coordinated with the Contracting Officer’s Representative (COR) and other sustainment/support entities as specified by the COR to assist with isolating issues whose full resolution may span the component groupings.

Table 1: VISNs supported under this scope AITC instances of RTLS Applications

(Centrak-Pulse) Enterprise Instance, per VISNgroup Parser instances Environmental Monitoring (CenTrak-Prism) per sitegroup instances

Asset Tracking Application (Infor) per VISN instances Cardiac Cath Lab Supply Tracking App – (WaveMark) Enterprise instance Shared Interfaces (VistAServices, Mule ESB) Enterprise instance Centralized Services (HA Proxy, PIV Proxy, Shared DBs, Utility) AITC Instances System Monitoring (Nagios) Enterprise Instance

* Enterprise app utilization X Virtual Server

RTLS sustainment efforts under this task order are inclusive of the following application software: CenTrak, Infor (AT) and Wavemark (CL). Common infrastructure to be supported includes that required to operate Single Sign-On (SSO) and F5 load balancer (configuration only). The complete list of software to be supported is specified in Section 5.0, Table 2. It also includes RTLS virtual servers sustainment.

The RTLS software sustainment effort will support O&M of the production, pre-production, development, and Software Quality Assurance (SQA) environments at the NDC. This includes applying patches and upgrades just as with the production environment. The sustainment effort will also verify the function and stability of upgrades in all environments prior to advancing to operational deployment into the production environment. This will include regression testing sufficient to verify basic functionality (e.g., login, search, asset tracking, reporting, accurate monitoring and synchronization of inventory).

All RTLS hardware at the NDC is maintained by VA and its sustainment and replacement are outside the scope of this TO. This TO does not include provisioning and maintenance of hardware, which is provided by AITC.

This RTLS Server Sustainment task order (TO) does not include software development, which is defined as Contractor modification to the baseline codebase of a product.

The scope of this TO as related to the RTLS architecture is outlined (within the dotted lines) with awareness of its interfaces as shown in Figure 1 below.

Figure 1: Scope of RTLS Sustainment

RTLS interfaces to external systems are software solutions orchestrated by a series of Enterprise Service Bus (ESB) flows. To support RTLS interfaces, VA uses the MuleSoft, a lightweight, open source ESB and integration framework that implements a communication messaging system between mutually interacting software applications. It is a Java-based ESB and integration platform to facilitate message routing and data transformation. Within the ESB flows, REST-ful web services are employed on both ends to facilitate communication. Communication with VistA is managed with a series of REST-ful web service methods designed for the RTLS Enterprise solution called VistaService.

The RTLS server sustainment effort under this TO includes all RTLS components supporting the following RTLS interfaces, which are:

1. VistALink modules: Integrated Funds Control, Accounting and Procurement-Generic Inventory Package (IFCAP-GIP), Automated Engineering Management System-Medical Equipment Reporting System (AEMS-MERS), Patient file, New Person/Employee file

2. Maximo inventory system

3. Cardiac Catheterization Lab system called Clinical Assessment, Reporting, and Tracking System for Cardiac Catheterization Laboratories (CART-CL).

There is a process whereby a newly tagged asset within VA Medical Centers (VAMC) is associated with records in AEMS-MERS or Maximo. This “tag-up” process involves the use of a Motorola handheld scanner (in a VA medical center) that is configured to use the ESB at NDC to reach into AEMS-MERS or Maximo to retrieve the asset details from one of those systems.

Some components located at the NDC are shared, either by VISNs located there, or by VISNs whose RTLS equipment is external to NDC, as follows:

1. Intra-NDC shared components:

a. Mule ESB servers

b. Single-sign-on (SSO) Apache servers

c. CenTrak GMS

d. Nagios

e. Structured Query Language (SQL) and Oracle database servers

f. Veterans Health Information Systems & Technology Architecture (VistA) interface servers – Weblogic/VistALink

g. Wavemark application

2. NDC shared components for VISNs inside and outside NDC:

a. ESB interface to reach Maximo

b. ESB interface used for handheld “tag-up” process (to pull information from AEMS-MERS or Maximo)

Sustainment of the interfaces, the interface middleware, and the servers that run the interfaces software (MULE, Weblogic) are outside the scope of this TO. They are mentioned here for informational purposes only. Troubleshooting issues with data presented to the ESB, or received from the ESB, is in scope of this TO.

RTLS software is highly virtualized, with software components spread across multiple virtual machines running on VA-provided hardware. A load balancer directs traffic to different RTLS servers, the number of which varies depending on the size of each VISN. To prevent outages, a high availability model is used to failover Virtual Machines (VM) and Storage Area Network (SAN) components. The list of virtual servers broken out by function is included as Government Furnished Information as RTLS Virtual Server List by Function.

APPLICABLE DOCUMENTS

The Contractor shall comply with the documents listed below.

1. 44 U.S.C. § 3541-3549, “Federal Information Security Management Act (FISMA) of 2002”

2. “Federal Information Security Modernization Act of 2014”

3. Federal Information Processing Standards (FIPS) Publication 140-2, “Security Requirements for Cryptographic Modules”

4. FIPS Pub 199. “Standards for Security Categorization of Federal Information and Information Systems,” February 2004

5. FIPS Pub 200, “Minimum Security Requirements for Federal Information and Information Systems,” March 2006

6. FIPS Pub 201-2, “Personal Identity Verification of Federal Employees and Contractors,” August 2013

7. 5 U.S.C. § 552a, as amended, “The Privacy Act of 1974”

8. Public Law 109-461, Veterans Benefits, Health Care, and Information Technology Act of 2006, title IX Information Security Matters

9. 10 U.S.C. § 2224, "Defense Information Assurance Program"

10. 42 U.S.C. § 2000d “Title VI of the Civil Rights Act of 1964”

11. VA Directive 0710, “Personnel Security and Suitability Program,” June 4, 2010, (https://www.va.gov/vapubs/index.cfm)

12. VA Handbook 0710, “Personnel Security and Suitability Program,” May 2, 2016 (https://www.va.gov/vapubs/index.cfm)

13. VA Directive 6102 (Internet/Intranet Services), August 5, 2019 (https://www.va.gov/vapubs/index.cfm)

14. VA Handbook 6102 (Internet/Intranet Services), August 5, 2019 (https://www.va.gov/vapubs/index.cfm)

15. Health Insurance Portability and Accountability Act (HIPAA); 45 CFR Part 160, 162, and 164; Health Insurance Reform: Security Standards; Final Rule dated February 20, 2003

16. VHA Directive 1605.05, Business Associate Agreements, November 17, 2020, (https://www.va.gov/vhapublications/ViewPublication.asp?pub_ID=9178)

17. 36 C.F.R. Part 1194 “Information and Communication Technology Standards and Guidelines,” January 18, 2017

18. Office of Management and Budget Circular A-130, “Managing Federal Information as a Strategic Resource,” July 28, 2016

19. U.S.C. Section 552a, as amended

20. Title 32 CFR 199, “Civilian Health and Medical Program of the Uniformed Services (CHAMPUS)”

21. NIST SP 800-66 Rev. 1, “An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule,” October 2008

22. Sections 504 and 508 of the Rehabilitation Act (29 U.S.C. Section § 794d), as amended, January 18, 2017

23. Homeland Security Presidential Directive (12) (HSPD-12), August 27, 2004

24. VA Directive 6500, “VA Cybersecurity Program,” February 24, 2021 (https://www.va.gov/vapubs/index.cfm)

25. VA Handbook 6500, “Risk Management Framework for VA Information Systems – Tier 3: VA Information Security Program,” February 24, 2021 (https://www.va.gov/vapubs/index.cfm)

26. VA Handbook 6500.2, “Management of Breaches Involving Sensitive Personal Information (SPI),” March 12, 2019 (https://www.va.gov/vapubs/index.cfm)

27. VA Handbook, 6500.5, Incorporating Security and Privacy into the System Development Lifecycle,” March 22, 2010 (https://www.va.gov/vapubs/index.cfm)

28. VA Handbook 6500.6, “Contract Security,” March 12, 2010 (https://www.va.gov/vapubs/index.cfm)

29. VA Handbook 6500.8, “Information System Contingency Planning,” April 6, 2011 (https://www.va.gov/vapubs/index.cfm)

30. VA Handbook 6500.10, “Mobile Device Security Policy,” February 15, 2018

31. VA Handbook 6500.11, “VA Firewall Configuration,” August 22, 2017

32. Office of Information and Technology (OIT) Process Asset Library (PAL) https://www.va.gov/process/. Reference Process Maps at https://www.va.gov/process/maps.asp and Artifact templates at https://www.va.gov/process/artifacts.asp

33. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Rev 5, “Security and Privacy Controls for Federal Information Systems and Organizations,” September 23, 2020 (includes updates as of 12/10/2020)

34. Federal Travel Regulation (FTR) (www.gsa.gov/federaltravelregulation)

35. One-VA Technical Reference Model (TRM) (https://www.va.gov/trm/TRMHomePage.aspx)

36. Federal Segment Architecture Methodology (FSAM) v1.0, December 2008

37. VA Directive 6508, “Implementation of Privacy Threshold Analysis and Privacy Impact Assessment,” October 15, 2014 (https://www.va.gov/vapubs/index.cfm)

38. VA Handbook 6508.1, “Procedures for Privacy Threshold Analysis and Privacy Impact Assessment,” July 30, 2015

39. VA Handbook 6510, “VA Identity and Access Management,” January 15, 2016

40. VA Directive and Handbook 6513, “Secure External Connections,” October 12, 2017

41. VA Directive 6300, “Records and Information Management,” September 21, 2018 (https://www.va.gov/vapubs/index.cfm)

42. VA Handbook, 6300.1, “Records Management Procedures,” March 24, 2010 (https://www.va.gov/vapubs/index.cfm)

43. NIST SP 800-37 Rev 2, “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy,” December 2018

44. OMB Memorandum “Security Authorization of Information Systems in Cloud Computing Environments,” December 8, 2011 (FedRAMP Policy Memorandum)

45. VA Directive 6609, “Mailing of Sensitive Personal Information,” May 20, 2011 (https://www.va.gov/vapubs/index.cfm)

46. VA Enterprise Technology Strategic Plan, February 28, 2014

47. VA Directive 0735, “Homeland Security Presidential Directive 12 (HSPD-12) Program,” October 26, 2015 (https://www.va.gov/vapubs/index.cfm)

48. VA Handbook 0735, “Homeland Security Presidential Directive 12 (HSPD-12) Program,” March 24, 2014 (https://www.va.gov/vapubs/index.cfm)

49. OMB Memorandum 05-24, “Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors,” August 5, 2005

50. OMB Memorandum M-19-17, “Enabling Mission Delivery Through Improved Identity, Credential, and Access Management,” May 21, 2019

51. OMB Memorandum, “Guidance for Homeland Security Presidential Directive (HSPD) 12 Implementation,” May 23, 2008

52. Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, December 2, 2011, (NOTE: Part A of the FICAM Roadmap and Implementation Guidance, v2.0, was replaced in 2015 with an updated Architecture (https://arch.idmanagement.gov/#what-is-the-ficam-architecture)

53. NIST SP 800-116 Rev 1, “Guidelines for the Use of Personal Identity Verification (PIV) Credentials in Facility Access,” June 2018

54. NIST SP 800-63-3, 800-63A, 800-63B, 800-63C, “Digital Identity Guidelines,” updated March 02, 2020

55. NIST SP 800-157, “Guidelines for Derived PIV Credentials,” December 2014

56. NIST SP 800-164, “Guidelines on Hardware-Rooted Security in Mobile Devices (Draft),” October 2012

57. Draft National Institute of Standards and Technology Interagency Report (NISTIR) 7981, “Mobile, PIV, and Authentication,” March 2014

58. VA Memorandum, VAIQ #7100147, “Continued Implementation of Homeland Security Presidential Directive 12 (HSPD-12),” April 29, 2011 (https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514)

59. IAM Identity Management Business Requirements Guidance document, May 2013, (https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514)

60. VA Memorandum “Personal Identity Verification (PIV) Logical Access Policy Clarification,” July 17, 2019, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4896

61. Trusted Internet Connections (TIC) 3.0 Core Guidance Documents, https://www.cisa.gov/publication/tic-30-core-guidance-documents

62. OMB Memorandum M-19-26, “Update to the Trusted Internet Connections (TIC) Initiative,” September 12, 2019

63. OMB Memorandum M-08-23, “Securing the Federal Government’s Domain Name System Infrastructure,” August 22, 2008

64. Sections 524 and 525 of the Energy Independence and Security Act of 2007, (Public Law 110–140), December 19, 2007

65. Section 104 of the Energy Policy Act of 2005, (Public Law 109–58), August 8, 2005

66. Executive Order 13834, “Efficient Federal Operations,” dated May 17, 2018

67. Executive Order 13221, “Energy-Efficient Standby Power Devices,” August 2, 2001

68. VA Directive 0058, “VA Green Purchasing Program,” July 19, 2013 (https://www.va.gov/vapubs/index.cfm)

69. VA Handbook 0058, “VA Green Purchasing Program,” July 19, 2013 (https://www.va.gov/vapubs/index.cfm)

70. Office of Information Security (OIS) VAIQ #7424808 Memorandum, “Remote Access,” January 15, 2014, https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28

71. Clinger-Cohen Act of 1996, 40 U.S.C. §11101 and §11103

72. “Veteran Focused Integration Process (VIP) Guide 4.0,” January 2021, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4371

73. VA Memorandum “Proper Use of Email and Other Messaging Services,” January 2, 2018, https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28

74. “DevSecOps Product Line Management Playbook” version 2.0, May 2021, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4946

75. NIST SP 500-267B Revision 1, ”USGv6 Profile,” November 2020

76. OMB Memorandum M-21-07, “Completing the Transition to Internet Protocol Version 6 (IPv6),“ November 19, 2020

77. Social Security Number (SSN) Fraud Prevention Act of 2017

78. Section 240 of the Consolidated Appropriations Act (CAA) 2018, March 23, 2018

79. VA Enterprise Cloud (VAEC) Technical Reference Guide, July 2018 version 1.3

80. RTLS Enterprise Data Architecture v.13.0

81. RTLS NDC Virtual Server List by Function

82. RTLS Solution Architecture Baseline v1

SCOPE OF WORK

The Contractor shall provide project management, Operation and Maintenance (O&M) preventative and corrective maintenance, documentation, and transition services for the RTLS system. The Contractor shall provide these services for the RTLS production, pre-production, development, and SQA environments deployed at the RTLS NDC, also known as AITC.

PERFORMANCE DETAILS

PERFORMANCE PERIOD

The period of performance (POP) shall be a base period of 12 months from the date of award with four 12-month option periods.

PLACE OF PERFORMANCE

Efforts under this TO shall be performed at Contractor facilities. The Contractor shall identify the Contractor’s place of performance in their Execution Plan submission.

TRAVEL OR SPECIAL REQUIREMENTS

The Government does not anticipate travel under this effort.

TECHNICAL EXPERTISE

In performance of the tasks in this PWS, the Contractor shall use and have expertise in the following software and technologies:

1. Microsoft SharePoint 2010, 2013 or later SharePoint versions, and related technologies

1. XML, XSL, XSLT

1. SQL Server 2012

1. Reporting tools including SQL Server Reporting Services (SSRS)

1. SQL Server Analysis Services (SSAS)

1. SQL Server Integration Services (SSIS)

1. Splunk

1. Nagios

1. Red Hat Linux system administration

1. Windows System Administration

1. Infor

1. Wavemark

1. CensiTrac

1. CenTrak

1. Oracle databases

1. MonetDB

1. MySQL

1. Java JDK/SE

1. RabbitMQ

1. OneVA Technical Reference Model (TRM)

SPECIFIC TASKS AND DELIVERABLES

The Contractor shall provide O&M sustainment services for the RTLS production, pre-production, development, and SQA environments to include RTL virtual servers and RTLS applications. There is no hardware sustainment required for this TO. O&M sustainment services shall be provided for the software components identified below, in Table 2. These services are detailed in Section 5.2 through Section 5.4, to include operating system patches/upgrades, RTLS software component patches/upgrades, network administration, software license installation, system configuration changes, and virtual machine reboots. Table 2 below, lists of the software components covered under this TO.

Table 2: Software Components Covered Under this Task Order

PROJECT MANAGEMENT

The Contractor shall identify a Single Point of Contact (SPOC) to oversee the O&M tasking for the RTLS at NDC. The Contractor SPOC shall be responsible for:

1. Effectively communicating and providing timely project progress to VA and Contractor team members using the activity progress report.

2. Ensuring the submission of contract deliverables

3. Coordinating, escalating, and resolving Contractor-related project issues.

4. Representing the Contractor in status meetings.

5. Complying with VA’s change management process.

REPORTING REQUIREMENTS

The Contractor shall manage the RTLS Sustainment work effort and provide a Monthly Activity Report. These reports shall convey the status of Contract performance. A standard format will be provided by VA and shall be utilized for submission of required information. Required information includes:

1. All planned or scheduled maintenance that will occur in the next reporting period.

2. Maintenance activity log showing all patches / upgrades / licenses installed, failures and faults detected, system performance deviations, including security vulnerabilities identified by VA from the monthly Nessus and on demand Oracle and SQL Server database scans, and the operational time to restore.

3. Customer support log which shall include a description of all support issues identified, severity level, and how the issues were resolved.

4. Corrective actions taken and status, whether closed/resolved or still open.

5. Anticipated closure date and roadblocks (if any) for open items.

6. All known significant issues or risks.

7. A summary of all closed and completed items.

Deliverable:

1. Monthly Activity Report

TECHNICAL KICKOFF MEETING

The Contractor shall hold a technical kickoff meeting within 10 days after award. The Contractor shall present, for review and approval by the Government, the details of the intended approach, work plan, and project schedule for each effort. The Contractor shall specify dates, locations (can be virtual), agenda (shall be provided to all attendees at least five (5) calendar days prior to the meeting), and meeting minutes (shall be provided to all attendees within three (3) calendar days after the meeting). The Contractor shall invite the Contracting Officer (CO), Contract Specialist (CS), COR, and the VA PM.

WEEKLY STATUS MEETING

The Contractor shall hold a weekly status meeting with the COR and technical Point of Contacts (POC) as specified by the COR to discuss all the items identified in Monthly Activity Report (section 5.1.1), and other issues as identified by the COR. The Contractor shall provide weekly status meeting minutes to all attendees within three (3) calendar days after the meeting.

INBOUND TRANSITION

The Contractor shall participate in activities performed to ease the inbound and outbound transition of the Contractor teams onto and off this sustainment contract.

The Contractor shall:

1. Provide phase-in transition planning and execution of all PWS-specific content by VA from existing Vendors associated with the programs during the transition period handing off work from outgoing vendor or Government personnel to the incoming vendor.

2. Work closely with the outgoing vendor in a left-seat, right-seat type of hand off to ensure knowledge transfer is thorough and all encompassing.

3. Conduct an initial Phase-In Transition Planning meeting within ten (10) days of award, with the VA COR, VA organizations identified by the COR and outgoing Vendor resources.

4. Document its approach and milestones to transfer the full lifecycle support requirements for all RTLS Program applications’ maintenance and application architecture responsibilities in a Phase-In Transition Plan. The Phase-In Transition Plan shall include:

a. Review of legacy program documentation, product backlog and associated user stories, and metrics and statistics.

b. The plan to participate, as an observer, in development and sustainment releases as well as maintenance updates and patches to be performed by the incumbent development Contractor for the purpose of facilitating knowledge transfer.

c. Milestone schedule of transition activities related to each existing module.

d. Roles and Responsibilities matrix showing key personnel for each module

e. The plan to transition current support services.

f. Details on accessing and assessment of application environment and tools.

g. Transition coordination schedule to meet with Government and Contractor representatives, including all VA organizations that hold sustainment responsibilities, to confirm demarcation of responsibilities and interface points for performance of work elements.

h. Transition schedule with tasks, duration, milestones, resource allocation, knowledge transfer sessions, and dates for completion of work transfer to Contractor.

i. Risks and associated risk mitigation plans.

j. Summary and schedule for Government-required training, clearance, and certification process.

k. Sections dedicated to the transition of Operational and Help Desk support with a particular emphasis on integration with the outgoing Vendor Phase Out schedule and obtaining system access (e.g., server administrator accounts) to support seamless hand-off of responsibilities.

5. Conduct a Phase-in Transition In Progress Review (IPR) within 10 days after the phase in transition plan meeting of the delivered plan with the VA COR, VA organizations identified by the COR, and outgoing Vendor resources.

6. Provide a weekly Phase-In Transition Status Report until the completion of the Knowledge Transfer / Phase-In Transition activities. The Contractor shall report:

a. Percent complete of GFI documentation review

b. Percent complete of code review

c. Percent complete of required project staffing

d. Risk identification and management

e. Percent complete of knowledge transfer.

The Contractor shall complete transition up to thirty (30) calendar days after award.

Deliverables:

A. Phase-In Transition Plan B. Weekly Phase-In Transition Status Report

Operation and MAINTENANCE (O&M) The Contractor shall deploy software updates and upgrades in the execution of RTLS preventive maintenance tasks. Additionally, the Contractor shall maintain and modify infrastructure system configurations to address functionality, security, connectivity or load issues. Most RTLS application minor updates are released once or twice a year, while major updates are done annually. Updates to any individual application may vary in a given period of performance.

For RTLS O&M, the Contractor shall:

1. Perform modifications to RTLS software installations and operational configurations to maintain and improve system performance, and to detect and correct latent faults in software and hardware products before they become operative faults. A latent fault (also called latent defect or latent condition) is one that is present but hidden from regular means of detection or yet to have an operational impact. An operative fault (also called effective fault) is a fault activity impacting nominal system operations or business functionality.

2. Monitor the performance of the RTLS system, including system resources such as processor, memory and disk utilization, and verify that performance thresholds are within nominal operating range, and take corrective action necessary to mitigate or relieve RTLS performance deviations. The Contractor shall log and notify VA of any performance deviation, and any known or suspected rationale for the deviation in the Maintenance Activity Log, which shall be included as part of the Monthly Activity Report (Section 5.1.1).

3. Engage in an ongoing inspection of RTLS to identify operative and latent defects in RTLS functions, software scripts, and software and hardware configuration. The Contractor shall make actionable recommendations that address any defects detected. Recommendations shall be verbally relayed to the COR and documented in the Maintenance Activity Log, which shall be included as part of the Monthly Activity Report (Section 5.1.1).

4. Coordinate with VA NDC/AITC POCs to determine timing windows for patch / upgrade installations. This may take place outside of NDC/AITC’s regular business hours.

5. Identify, download and install or maintain the installation of RTLS application software patches and upgrades.

6. Coordinate with VA POCs identified by the COR to shut down, reboot or restart RTLS systems (e.g., Infor, CenTrak, Wavemark) and RTLS supporting Systems (e.g., SSOi), following VA or RTLS IT maintenance, recovery or software patching.

7. Proactively download Linux patches and upgrades from a server identified by VA, install those patches and reboot the patched VMs.

8. Verify correct operation of RTLS after every patch installation.

9. If operating system patches are shown to interfere with RTLS operation, coordinate with VA POCs identified by the COR before backing out any operating system patch(es).

10. Provide RTLS network administration support to include maintenance of the application connection ports, firewall, load-balancer, Secure Socket Layer Off-loading and Single Sign-On Integration (SSOi) requirements and configurations.

SOFTWARE UPDATES, UPGRADES AND ADMINISTRATION

The application components of RTLS are hosted on platforms that contain VA standard operating systems, virtual machines, and ancillary software. Some of the software listed in Table 2 are sub-components of the RTLS application software. The maintenance updates and upgrades to VA standard environments are the responsibility of VA Office of Information & Technology (OIT). The Contractor shall be responsible for identifying and downloading updates or upgrades to these RTLS components and sub-components. The Contractor shall:

1. Perform the installation, configuration, update (patching operational software) and/or upgrade (replacing or supplementing the software baseline) of RTLS software to mitigate the development of future faults, correct latent faults (present but hidden from routine {i.e., non-extraordinary} means of detection), rectify operative faults, restore nominal operations, or enhance component and system performance/capacity. For RTLS application software, the Contractor may expect approximately one major update and two to three minor updates a year. Linux patches are issued by VA monthly. The Contractor shall coordinate with the NDC PM to schedule installation before the next set of patches becomes available (less than 30 days). For RTLS application patches, the Contractor shall coordinate with the NDC PM to schedule installation within 30 days from when the software update is available. If issues are encountered, this timeframe may be extended with agreement from the COR.

1. Notify AITC PM and COR three weeks in advance of installing new RTLS application releases or upgrades or any other disruptive maintenance activity in any environment. The Contractor shall delay or terminate any planned update or upgrade upon email notification from the COR.

1. Perform the installation of software patches, new releases and software updates in the Dev and SQA environments to determine their impact prior to performing the same installations in the pre-production environment. New releases and upgrades may provide new functionality as well as any needed system corrections.

1. Ensure that the installation, operation, maintenance, updating, and patching of software shall not alter prior configuration settings or those from the VA approved configuration.

1. Verify the function and stability of upgrades in all environments (subject to the connectivity limits of those environments) prior to advancing to operational deployment into the production environment. This will include regression testing sufficient to verify basic functionality (e.g., login, search, asset tracking, reporting, accurate monitoring and synchronization of inventory).

1. Perform routine RTLS system administration functions and serve as system administrator for all RTLS applications. In addition to system patches and updates, the Contractor shall monitor system logs and resource utilization, and archive system data and audit logs as needed. Server operating system administration (apart from patches) is the responsibility of NDC staff.

1. Provide written notice to VA that each patch has been validated as not affecting the Systems within 10 working days when security fixes involve installing third party patches in pre-production (such as Linux Red Hat). Notification shall come in the form of an email to the COR.

1. Provide VA any necessary information to update the One-VA TRM entry for any software components updated.

1. Contractor shall provide supporting data as requested by the COR to complete necessary VA IT requests such as Authority to Operate (ATO) and TRM waivers.

SOFTWARE LICENSE INSTALLATION

All RTLS software licenses will be purchased by VA and given to the Contractor for installation. For RTLS software license installation, the Contractor shall:

1. Receive from the PM/COR, available license renewal data.

1. Install RTLS licenses, upon the authorization of the PM/COR. Licenses to operate RTLS software applications at the NDC are listed in Table 2 (Software Components Covered Under This Contract).

CORRECTIVE MAINTENANCE

Corrective Maintenance is the reactive maintenance performed to identify, isolate, and rectify RTLS operating faults.

For RTLS corrective maintenance, the Contractor shall:

1. Perform troubleshooting to identify and isolate faults causing any failure or degradation of service in RTLS components and systems.

1. VA will perform Federal Information Security Management Act (FISMA) compliance audits and Nessus scans on a monthly basis, and the Contractor shall address and resolve all security remediation and vulnerabilities identified within the timeframe specified below, starting from notification of findings. VA maintains a tracking database for all security scan findings and compliance audits. The Contractor shall update that database to indicate the status of issue resolution and/or the plan to resolve issues that will take longer to resolve, in case of delays beyond the Contractor’s control (e.g., a VA delay or vendor dependency for software patches). Based on historical data, the Contractor may expect approximately 10 new findings per month (1/8 critical priority, 1/2 high priority, 3/8 medium priority).

1. Critical – patches shall be tested and applied within 30 days

1. High – patches shall be tested and applied within 60 days

1. Moderate – patches shall be tested and applied within 90 days

1. Low – the System owner will determine the patching timeframe

1. Emergent – patches shall be tested and applied as soon as possible

1. Respond to and resolve notifications that RTLS servers are down.

1. Administer RTLS subsystem databases. This includes maintaining database synchronization with the backup site at Philadelphia Information Technology Center (PITC), addressing database security remediation, capacity planning, performance monitoring, troubleshooting, modification of database tables, allocating additional space and archiving data as required by the COR. Coordinate with VA POCs if new storage hardware is added, to configure new storage space for database use. VA will grant administrator privileges to Contractor staff to carry out database administration.

1. Troubleshoot, isolate and repair connectivity and communication issues for data presented to, or received from, the Mule ESB. Resolution of these issues may require coordination with other POCs as identified by the COR.

CUSTOMER SUPPORT

The Contractor shall work to resolve issues identified by the PM or COR. The source of these defects may be Tier 2 or 3 trouble tickets from another RTLS support contract, or an issue identified by the COR or PM. During regular business hours (7:00am to 7:00pm Eastern), the Contractor shall:

1. Respond to service requests from COR or designee (via telephone or email) to resolve or support the troubleshooting, identification and resolution of RTLS technical requests which involve RTLS components at the NDC. The Contractor shall log all requests that are received in the Maintenance Activity Log as part of the Monthly Activity Report (Section 5.1.1).

2. Classify all service request received by assigning a severity level, in accordance with Table 3 below. The Contractor may anticipate 2-3 service requests per month, typically of the Non-Critical and Important severity.

3. Coordinate with the COR if access to resources at a VAMC are required to fully diagnose or resolve an issue and work collaboratively with the POC(s) identified by the COR to resolve issues within NDC boundaries as depicted in Figure 1. RTLS malfunctions may originate within NDC boundaries, outside NDC boundaries, or both, if the NDC components have a dependency on external RTLS components (i.e., RTLS components at a VAMC).

4. Collaborate with any identified POCs to cooperatively troubleshoot and resolve issues.

5. Provide issue resolution response to resolve faults and requests, in accordance with the response timeline provided in Table 3 below. Issues, status and resolution notification shall be communicated to the COR.

6. Document all customer support issues in the Customer service log, a component of the Monthly Activity Report (section 5.1.1)

7. Develop and submit service requests to COR-identified VA POCs to request OIT support services to resolve RTLS faults and other operating problems caused by components outside the maintenance responsibility of this contract.

Table 3: Event Response Time Intervals

DOCUMENTATION OF STANDARD OPERATING PROCEDURES

For the RTLS Standard Operating Procedures (SOP), the Contractor shall:

1. Develop, update twice a year at a minimum, and submit for review, RTLS Sustainment SOP describing RTLS SOP to the COR. The content of the SOP shall be inclusive of operations and maintenance procedures, configuration and change management, systems recovery point objectives, record maintenance and performance metrics to be monitored and reported.

2. Adhere to the procedures documented in the SOP, upon acceptance and approval by the COR.

Deliverable:

A. RTLS Sustainment Standard Operating Procedures

OPTIONAL TASK ONE - OUTBOUND TRANSITION

If exercised by VA, the Contractor shall participate in activities to perform outbound transition of contractor teams off this sustainment contract.

The Contractor shall provide a Transition Plan for 60 days of outgoing transition support for transitioning work from the current contract to a follow-on contract or Government entity. In accordance with the Government-approved plan, the Contractor shall complete the transition from this contract to a new support provider, while ensuring no breaks in service availability and minimal transition impact to the user community. This shall include formal coordination with Government staff and successor staff and management. It shall also include delivery of copies of all artifacts delivered under this contract, as well as existing policies and procedures, and delivery of baseline metrics and statistics. This Transition Plan shall include, but is not limited to:

1. Coordination with Government representatives.

2. Review, evaluation and transition of current support services.

3. Transition of historic data to new Contractor system.

4. Transition of network accounts.

5. Plans for migrating maintenance operations, operating data, domain knowledge, license status

6. Transfer of all necessary business and/or technical documentation.

7. Orientation phase and program to introduce Government and Contractor personnel, programs, and users to the Contractor's team, tools, methodologies, and business processes.

The Contractor shall also produce a list of all assets associated with the project. This includes all software assets, specification of support environments, tools; hardware and software licenses, warranties, and maintenance agreements; documentation, and any other assets that must be maintained throughout the asset lifecycle.

This list of assets shall be delivered as a Certificate of Transition Completion for all assets, which will be signed by the PM and the COR to indicate acceptance.

Deliverables:

A. Transition Plan B. Certificate of Transition Completion

GENERAL REQUIREMENTS

ENTERPRISE AND IT FRAMEWORK

VA TECHNICAL REFERENCE MODEL

The Contractor shall support the VA enterprise management framework. In association with the framework, the Contractor shall comply with OIT Technical Reference Model (VA TRM). The VA TRM is one component within the overall Enterprise Architecture (EA) that establishes a common vocabulary and structure for describing the information technology used to develop, operate, and maintain enterprise applications. Moreover, the VA TRM, which includes the Standards Profile and Product List, serves as a technology roadmap and tool for supporting OIT. Architecture & Engineering Services (AES) has overall responsibility for the VA TRM.

FEDERAL IDENTITY, CREDENTIAL, AND ACCESS MANAGEMENT (FICAM)

The Contractor shall ensure Commercial Off-The-Shelf (COTS) product(s), software configuration and customization, and/or new software are Personal Identity Verification (PIV) card-enabled by accepting HSPD-12 PIV credentials using VA Enterprise Technical Architecture (ETA), https://www.ea.oit.va.gov/EAOIT/VA_EA/Enterprise_Technical_Architecture.asp, and VA Identity and Access Management (IAM) approved enterprise design and integration patterns, https://www.oit.va.gov/library/recurring/edp/index.cfm. The Contractor shall ensure all Contractor delivered applications and systems comply with the VA Identity, Credential, and Access Management policies and guidelines set forth in VA Handbook 6510 VA Identity and Access Management, VA Handbook 0735 Homeland Security Presidential Directive 12 (HSPD-12) Program, and align with the Federal Identity, Credential, and Access Management Roadmap and Implementation Guidance v2.0.

The Contractor shall ensure all Contractor delivered applications and systems provide user authentication services compliant with the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-63-3, VA Handbook 6500 Appendix F, “VA System Security Controls”, and VA IAM enterprise requirements for direct, assertion based authentication, and/or trust based authentication, as determined by the design and integration patterns. Direct authentication at a minimum must include Public Key Infrastructure (PKI) based authentication supportive of PIV card and/or Common Access Card (CAC), as determined by the business need.

The Contractor shall ensure all Contractor delivered applications and systems conform to the specific Identity and Access Management PIV requirements set forth in the Office of Management and Budget (OMB) Memoranda M-05-24, M-19-17, and NIST Federal Information Processing Standard (FIPS) 201-2. OMB Memoranda M-05-24 and M-19-17 can be found at: https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2005/m05-24.pdf, and https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf respectively. Contractor delivered applications and systems shall be on the FIPS 201-2 Approved Product List (APL). If the Contractor delivered application and system is not on the APL, the Contractor shall be responsible for taking the application and system through the FIPS 201 Evaluation Program.

The Contractor shall ensure all Contractor delivered applications and systems support:

1. Automated provisioning and are able to use enterprise provisioning service.

2. Interfacing with VA’s Master Person Index (MPI) to provision identity attributes, if the solution relies on VA user identities. MPI is the authoritative source for VA user identity data.

3. The VA defined unique identity (Secure Identifier [SEC ID] / Integrated Control Number [ICN]).

4. Multiple authenticators for a given identity and authenticators at every Authenticator Assurance Level (AAL) appropriate for the solution.

5. Identity proofing for each Identity Assurance Level (IAL) appropriate for the solution.

6. Federation for each Federation Assurance Level (FAL) appropriate for the solution, if applicable.

7. Two-factor authentication (2FA) through an applicable design pattern as outlined in VA Enterprise Design Patterns.

8. A Security Assertion Markup Language (SAML) implementation if the solution relies on assertion-based authentication. Additional assertion implementations, besides the required SAML assertion, may be provided as long as they are compliant with NIST SP 800-63-3 guidelines.

9. Authentication/account binding based on trusted Hypertext Transfer Protocol (HTTP) headers if the solution relies on Trust based authentication.

10. Role Based Access Control.

11. Auditing and reporting capabilities.

12. Compliance with VIEWS 00155984, PIV Logical Access Policy Clarification https://www.voa.va.gov/DocumentView.aspx?DocumentID=4896.

The required Assurance Levels for this specific effort are Identity Assurance Level 3, Authenticator Assurance Level 3, and Federation Assurance Level 3.

INTERNET PROTOCOL VERSION 6 (IPV6)

The Contractor solution shall support Internet Protocol Version 6 (IPv6) based upon the memo issued by the Office of Management and Budget (OMB) on November 19, 2020 (https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf). IPv6 technology, in accordance with the USGv6 Program (https://www.nist.gov/programs-projects/usgv6-program/usgv6-revision-1), NIST Special Publication (SP) 500-267B Revision 1 “USGv6 Profile” (https://doi.org/10.6028/NIST.SP.500-267Br1), and NIST SP 800-119 “Guidelines for the Secure Deployment of IPv6” (https://doi.org/10.6028/NIST.SP.800-119), compliance shall be included in all IT infrastructures, application designs, application development, operational systems and sub-systems, and their…