S02 - Attachment A - RTLS_Handheld_RSD.xlsx
XLSX spreadsheet 93 KB Posted
- Attached to
- R499--RTLS Asset Tracking Handheld Software Application (VA-22-00100209) Federal contract opportunity
- Solicitation number
- 36C10A22Q0248
About this file
This document is a Requirements Traceability Matrix (RTM) for a Real Time Location System (RTLS) Asset Tracking Handheld Software Application. The RTM outlines fifteen key requirement categories for the handheld solution including accessibility, business rules, design constraints, documentation, functional specifications, graphical user interface specifications, performance specifications, incident response times, system reliability, security specifications, security for user authentication and access management, support for Internet Protocol Version 6, security requirements for the Trusted Internet Connection initiative, system features, and training. The handheld solution must be compatible with iOS, integrate with VA identity management systems using Personal Identity Verification credentials, meet various security, reliability and performance standards, and support real-time locating of RFID-tagged assets. The contractor must provide end user training and help desk support with defined response times for critical, medium and low severity incidents. The related federal contract opportunity is solicitation number 36C10A22Q0248 being offered by the Department of Veterans Affairs Technology Acquisition Center Austin for an RTLS Asset Tracking Handheld Software Application.
View the file
Other files for this federal contract opportunity
| File | Type | Posted |
|---|---|---|
| S02 - Attachment C - RTLS Handheld Pricing Spreadsheet.xls | XLS spreadsheet | |
| 36C10A22Q0248_1.docx | DOCX document | |
| S02 - Attachment D-List of Applicable Documents.docx | DOCX document | |
| S02 - Attachment B - VA Sites Currently using RTLS.xlsx | XLSX spreadsheet | |
| S02 - 36C10A22Q0248 - RTLS Handheld RTM.docx | DOCX document |
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Cover Page
Real Time Location System
| Asset Tracking HandHeld |
| Requirements |
Traceability Matrix
Version History
| Date | Author | Version | Description |
| 7/11/22 | BWT | 1 | Initial draft |
| 9/2/22 | BWT | 5 | Inserted ystem features pulled from the National RTLS RSD |
Removed passive inventory require,emts
RTLS HH
| Attachment A: Requirement Specification Document | |||||||||||
| Performance Work Statement | Requirement Specification | Test Evaluation | |||||||||
| Source (Base PWS) | PWS Requirement (s) | Requirement Category | Requirement ID | Requirement Description | Test Case ID | Test Description | Test Date | Test Results (Pass/Fail/NA) | Defects | Comments | |
| RTLS_Handheld_PWS | |||||||||||
| Section 6.2 - Handheld Software Requirement | 1. Accessibility | HH 1.1 | The RTLS Handheld solution shall be accessible via a government issued VA TRM approved iPhone, compatible with iPhone accessibility features, and shall be available for download by authorized user | ||||||||
| RTLS_Handheld_PWS | Section 6.2 - Handheld Software Requirement | 2. Business Rules | HH 2.1 | The RTLS Handheld solution shall not allow a duplicate entry of an asset to a given facility and shall provide notification to the user that the asset is already in the system. | |||||||
| 2. Business Rules | HH 2.2 | The RTLS Handheld solution shall allow a tag that has been decommissioned to be associated with a new asset. | |||||||||
| 2. Business Rules | HH 2.3 | The RTLS Handheld solution shall allow decommissioning of any asset under any condition. | |||||||||
| 2. Business Rules | HH 2.4 | The RTLS Handheld solution shall include permission based access specifically for reporting features | |||||||||
| 2. Business Rules | HH 2.5 | The RTLS Handheld solution shall include permission based system administration for user management | |||||||||
| RTLS_Handheld_PWS | Section 7.1.2 - Federal Identity, Credential and Access Management (FICAM) | ||||||||||
| 3. Design Constraints | HH 3.1 | The RTLS Handheld solution shall be compliant with NIST Federal Information Processing Standard (FIPS) and shall be compatible with iOS software | |||||||||
| 3. Design Constraints | HH 3.2 | The RTLS Handheld solution shall be compatible with Transport protocol: HTTPS | |||||||||
| RTLS_Handheld_PWS | Section 6.6 - Training | 4. Documentation | HH 4.1 | The Contractor shall provide a user guide for the RTLS Handheld solution in PDF format that addresses: |
• Installation of software on user device
• Access instructions
• Tagging process, instructions, guidelines, and best practices
• Report generation and access
• Frequently Asked Questions (derived from Help Desk Queries)
• Use of Help Desk to answer user questions RTLS_Handheld_PWS Section 6.2 - Handheld Software Requirement Section 7.1.1 VA Technical Reference Model
| 5. Functional Specifications | HH 5.1 | The RTLS Handheld solution shall be capable of scanning and commissioning CenTrak® active RFID tags in Infor® LBI using built-in phone camera with VA Technical Reference Model (TRM) approved phones | ||
| 5. Functional Specifications | HH 5.2 | The RTLS Handheld solution shall provide a downloadable list for items to be commissioned | ||
| 5. Functional Specifications | HH 5.3 | The RTLS Handheld solution shall be capable of scanning bar codes | ||
| 5. Functional Specifications | HH 5.4 | The RTLS Handheld solution shall be capable of scanning and decommissioning CenTrak® active RFID tags in Infor® LBI using built-in phone camera with VA Technical Reference Model (TRM) approved phones | ||
| 5. Functional Specifications | HH 5.5 | The RTLS Handheld solution shall be compatible with production versions of iOS on the VA Technical Reference Model (TRM) | ||
| 5. Functional Specifications | HH 5.6 | The RTLS Handheld solution shall support Bluetooth-connected FIPS Compliant Hardware | ||
| 5. Functional Specifications | HH 5.7 | The RTLS Handheld solution shall include the following reporting features: |
• Tags commissioned
• Tags commissioned by user
• Tags decommissioned
• Tags decommissioned by user
5. Functional Specifications HH 5.8 The RTLS Handheld solution shall include the following query features:
• Ability to view status of tags
• Prevention of commissioning of assigned tags
| 5. Functional Specifications | HH 5.10 | The RTLS Handheld solution shall provide the capability to transfer data to the RTLS system wirelessly, where available. |
| 5. Functional Specifications | HH 5.12 | The RTLS Handheld solution shall provide the capability to read a location off of a barcode. (Barcodes typically affixed at entries to rooms and other areas). |
| 5. Functional Specifications | HH 5.13 | The RTLS Handheld solution shall provide the capability to manually enter its current location. |
| 5. Functional Specifications | HH 5.14 | For wirelessly enabled handheld scanners, the RTLS Handheld solution shall provide the capability to identify its current location. |
| 5. Functional Specifications | HH 5.15 | The RTLS Handheld solution shall give an error when it cannot sync with Infor® LBI |
| 5. Functional Specifications | HH 5.16 | The RTLS Handheld solution shall enable other RTLS mobile utility modules to include |
• Battery Management (optional task)
• Wifi Accuracy Testing (optional task)
• Ability to work in offline mode (no network connectivity)
• Automatic timeout after 5 minutes for of users that are not actively utilizing the application
| 5. Functional Specifications | HH 5.17 | The RTLS Handheld solution shall provide data encryption in transit and at rest | ||
| 5. Functional Specifications | HH 5.18 | The RTLS Handheld solution shall allow for the commissioning and/or decommissioning a tag and asset in under 60 seconds. | ||
| RTLS_Handheld_PWS | Addendum A - Additional VA Requirements, Consolidated: Section 508 - Information and Communication Technology (ICT) Standards | 6. Graphical User Interface (GUI) Specifications | HH 6.1 | The RTLS Handheld solution must meet 508 compliance requirements on the iPhone |
| RTLS_Handheld_PWS | Section 6.2 - Handheld Software Requirement | 7. Performance Specification | HH 7.1 | Transaction time between the tag up activity and when data is associated in Infor® LBI shall be less than 60 seconds |
| 7. Performance Specification | HH 7.2 | The RTLS Handheld solution shall support at least 5 concurrent users per facility. Facility is defined by a facility that has a unique site ID. | ||
| RTLS_Handheld_PWS | Section 6.5.1.1 - Help Desk Incident Response | 8. Incident Response Times | HH 8.1 | The contractor shall provide an acknowlegement within 60 minutes of receipt/notification of a Critical severity incident and take immediate action to ensure reported incident is resolved. Average resolution time shall be no longer than 8 hours. |
A Critical severity incident is defined as meeting one or more of the following criteria:
• Complete loss of functionality/system
• Functionality severely degraded
• Loss of those features or functionality that may compromise: (i) medical decisions, (ii) delivery of patient care, (iii) disclosure of confidential information
8. Incident Response Times HH 8.2 The contractor shall provide an acknowlegement within 120 minutes of receipt/notification of a Medium severity incident and ensure a plan of action is put in place that defines the resolution time. Average resolution time shall be no longer than 12 hours.
A Medium severity incident is defined as meeting the following criteria:
• Disruption or a partial loss of the system, but the system is usable
8. Incident Response Times HH 8.3 The contractor shall provide an acknowlegement within 24 hours of receipt/notification of a Low severity incident and appropriate resources are assigned within 48 hours. Average resolution time shall be no longer than 80hours.
A Low severity incident is defined as meeting the following criteria:
• Customer is experiencing issues that require technical advice or recommendation for the best solution and/or have slight impact on the operating environment RTLS_Handheld_PWS Section 6.2 - Handheld Software Requirement 9. System Reliability HH 9.1 The RTLS Handheld solution shall meet or exceed the following reliability standards:
• Availability – 95%
• Mean Time Between Failures (MTBF) – 3 months
• Mean Time to Repair (MTTR) – 3 days, 36 hours
• Accuracy – 95% commission rate The RTLS Handheld shall require no more than 8 hours of maintenance per month. Servicing and maintenance is expected to occur on the weekends during periods of least usage.
| 10. Security Specifications | HH 10.1 | The RTLS Handheld solution shall be integrated with VA PIV D/SSOi | |||
| 10. Security Specifications | HH 10.2 | The RTLS Handheld solution shall comply with VA Security Compliance/Mobile Application "White Listing" process and be included on VA application White List. | |||
| RTLS_Handheld_PWS | Section 6.3 - Integration Services | ||||
| Section 7.1.2 Federal Identity Credential and Access Management | 11. Security - User Authentication and Access Management | HH 11.1 | 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. | ||
| 11. Security - User Authentication and Access Management | HH 11.2 | 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. | |||
| 11. Security - User Authentication and Access Management | HH 11.3 | 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. | |||
| 11. Security - User Authentication and Access Management | HH 11.4 | 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.
11. Security - User Authentication and Access Management HH 11.5 The Contractor shall ensure all Contractor delivered applications and systems support:
Automated provisioning and are able to use enterprise provisioning service.
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.
The VA defined unique identity (Secure Identifier [SEC ID] / Integrated Control Number [ICN]).
Multiple authenticators for a given identity and authenticators at every Authenticator Assurance Level (AAL) appropriate for the solution.
Identity proofing for each Identity Assurance Level (IAL) appropriate for the solution.
Federation for each Federation Assurance Level (FAL) appropriate for the solution, if applicable.
Two-factor authentication (2FA) through an applicable design pattern as outlined in VA Enterprise Design Patterns.
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.
Authentication/account binding based on trusted Hypertext Transfer Protocol (HTTP) headers if the solution relies on Trust based authentication.
Role Based Access Control.
Auditing and reporting capabilities.
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.
| RTLS_Handheld_PWS | Section 7.1.3 Trusted Internet Connection | 12. Security - Internet Protocol Version 6 (IPV6) | HH 12.1 | 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 integration |
| 12. Security - Internet Protocol Version 6 (IPV6) | HH 12.2 | The Contractor shall ensure all devices support native IPv6 and dual stack (IPv6 / IPv4) connectivity without additional memory or other resources being provided by the Government, so that they can function in a mixed environment. | ||
| 12. Security - Internet Protocol Version 6 (IPV6) | HH 12.3 | The Contractor shall ensure all public/external facing servers and services (e.g. web, email, DNS, ISP services, etc.) support native IPv6 and dual stack (IPv6 / IPv4) users and all internal infrastructure and applications shall communicate using native IPv6 and dual stack (IPv6 / IPv4) operations | ||
| RTLS_Handheld_PWS | Section 7.1.3 Trusted Internet Connection | 13. Security - Trusted Internet Connection (TIC) | HH 13.1 | The Contractor solution shall meet the requirements outlined in Office of Management and Budget Memorandum M-19-26, “Update to the Trusted Internet Connections (TIC) Initiative“ (https://www.whitehouse.gov/wp-content/uploads/2019/09/M-19-26.pdf), VA Directive 6513 “Secure External Connections”, and shall comply with the TIC 3.0 Core Guidance Documents, including all Volumes and TIC Use Cases, found at the Cybersecurity & Infrastructure Security Agency (CISA) (https://www.cisa.gov/publication/tic-30-core-guidance-documents). |
Any deviations must be approved by the VA TIC 3.0 Working Group at vaoisesatic30team@va.gov.
| Section 6.2 - Handheld Software Requirement | 14. System Features | HH 14.1 | The RTLS Handheld solution must have the ability to run reports on the commissioning process | |
| 14. System Features | HH 14.2 | The RTLS Handheld solution shall display an alert when there is a loss in connectivity. | ||
| 14. System Features | HH 14.3 | The RTLS Handheld solution shall operate outside the Medical Telemetry Frequency Range. | ||
| 14. System Features | HH 14.4 | The RTLS Handheld solution shall provide the capability of synching the inventory data with RTLS. | ||
| 14. System Features | HH 14.5 | The RTLS Handheld solution shall dynamically monitor itself to determine if all its components are working properly. | ||
| RTLS_Handheld_PWS | Section 6.6 - Training | 15. Training | HH 15.1 | The contractor shall provide virtual end user training to include |
• Access instructions
• Commissioning and decommissioning of inventory
• Software installation and operation
• Troubleshooting and maintenance
• Report and query generation
Removed
| Requirement Category | Requirement ID | Requirement Description | Comments |
| 5. Functional Specifications | HH 5.9 | The RTLS Handheld Solution shall provide the capability to scan both 1D and 2D barcodes. | remove (passive inventory) |
| 5. Functional Specifications | HH 5.11 | The RTLS Handheld solution shall provide the capability to sync information with a RTLS workstation when docked | remove |
| 5. Functional Specifications | HH 5.15 | The RTLS handheld solution shall operate and communicate at a power level and frequency that does not interfere with any other existing devices in the medical center at the time of task order contract award. | remove |
| 5. Functional Specifications | HH 5.17 | RTLS handheld solution shall be capable of functioning in a dense asset identification environment such as a warehouse storage room or clean utility room | remove (passive inventory) |
| 7. Multi-divisional Specification | HH 7.1 | The RTLS Handheld solution shall enable a minimum of five (5) and a maximum of 10 simultaneous users per facility. Facility is defined by a facility that has a unique site ID determined by VistA | remove |
| 14. System Features | HH 14.6 | The RTLS shall accept data from handheld devices as well as fixed position readers | remove (passive inventory) |
| 14. System Features | HH 14.7 | The RTLS handheld Solution shall provide the capability to perform an inventory. | remove (passive inventory) |
| 14. System Features | HH 14.9 | The RTLS Handheld solution for passive RFID tagged assets downloads the expected inventory based on a location scan for the location which is to be inventoried. The inventory attributes include asset description, asset quantity and tag IDs. | remove (passive inventory) |
| 14. System Features | HH 14.10 | While performing an inventory of an area, the RTLS Handheld solution shall store the tag ID of items observed. | remove (passive inventory) |
| 14. System Features | HH 14.11 | While performing an inventory of an area, the RTLS Handheld solution shall keep a running tally of which items were observed and which items remain to be found. | remove (passive inventory) |
| 14. System Features | HH 14.12 | The RTLS Handheld solution shall provide the user the capability to indicate completion of scanning an area. | remove (passive inventory) |
| 14. System Features | HH 14.13 | The RTLS Handheld solution shall display to the user a list of items still missing with the following information for each item: |
- EE Number
- Station Number
- Serial Number
| - Model Number | remove | ||
| 14. System Features | HH 14.14 | The RTLS Handheld solution shall display to the user a list of items found that are not in their assigned area, with the following information for each item: |
- EE Number
- Station Number
- Serial Number
| - Model Number | remove | |||
| 14. System Features | HH 14.16 | RTLS handheld solution shall be capable of functioning in a dense asset identification environment such as a warehouse storage room or clean utility room | remove | |
| 14. System Features | HH 14.17 | The RTLS handheld scanner shall be able to discretely identify all tagged items in a dense location without false positive or false negative identification. | remove | |
| 14. System Features | HH 14.19 | Exciters/readers, (mounted and mobile handheld, under Contractor-defined conditions), shall be capable of accurately scanning passive tags from a standoff distance of at least one meter and shall not interfere with medical and other care-critical device operation and communications. | remove |
File details come from the government source that posted it. Updated .