S06 - 36C10A25R0002 0003 Attachments D1-D.3.xlsx
XLSX spreadsheet 30 KB Posted
- Attached to
- VA Modernized Messaging Software as a Service (SaaS) Federal contract opportunity
- Solicitation number
- 36C10A25R0002-0003
About this file
This document is a functionality checklist and service model questionnaire for a VA Modernized Messaging Software as a Service (SaaS) solicitation (Solicitation Number: 36C10A25R0002-0003). The detailed attachment outlines comprehensive technical requirements for a secure, HIPAA-compliant messaging application designed for healthcare communication, specifically targeting VA medical centers. Key functionality specifications include robust privacy and security features, message escalation capabilities, role-based authentication, and specific use cases for clinical communication such as peer-to-peer messaging, group communications, and on-call staff coordination.
The solution must meet stringent performance indicators, including 99.95% Wi-Fi availability, 4-hour restoration time, and 100-millisecond response time. Critical technical requirements mandate complete data separation between government and personal devices, secure transmission of sensitive information (PII, PHI, SPI), customizable notifications, near real-time message delivery confirmations, and the ability to create role-based profiles and communication hierarchies. The solicitation is issued by the Department of Veterans Affairs Technology Acquisition Center in Austin, with the current amendment extending the closing date to 10/31/2025.
View the file
Other files for this federal contract opportunity
| File | Type | Posted |
|---|---|---|
| S06 - 36C10A25R0002 0003 Amended RFP.pdf | ||
| S06 - 36C10A25R0002 0003.pdf | ||
| 36C10A25R0002 Published QA 10.21.25.xlsx | XLSX spreadsheet |
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
D.1 Functionality Checklist 36C10A25R0002 Attachment D.1 - Functionality Checklist
| PWS Reference Section | Requirement Description |
| B.4.9 | MESSAGING SOFTWARE APPLICATION PRIVACY AND SECURITY |
| B.4.9.1 | The software application messaging solution shall partition on non-GFE BYOD the separation of 100% of all Government data and non-GFE BYOD data. |
| B.4.9.2 | The software application messaging solution shall ensure 100% privacy of non-GFE BYOD data. |
| B.4.9.2 | The software application messaging solution shall be capable of audit trails that journal and capture user activities with Government data. |
| B.4.9.2 | The Contractor shall provide a solution that supports transmitting text, images, pictures, and documents that protects Personally Identifiable information (PII), Protected Health Information (PHI), and Sensitive Personal Information (SPI), highlighting the use of the camera as a feature within the application solution (not external to the application). |
| B.4.9.2 | The solution shall prevent the Government from having access to the BYOD personal data and personal applications. |
| B.4.9.2 | The solution shall have device screen display personalized passcode login authentication. |
| B.4.10 | MESSAGING SOFTWARE APPLICATION FUNCTIONALITY |
| B.4.10 | The solution loading content shall respond between 1 to 10 seconds without user long loading time and lag that significantly detract from the user experience. |
| B.4.10 | The solution shall have the functionality that sends messages to an individual and or a group. |
| B.4.10 | The solution shall have the capability and functionality to track and confirm the status of messages by acknowledging received and read. |
| B.4.10 | The solution shall have the capability and functionality to create and define groups, create role base profiles, role base login designations, role base hierarchy, and role base availability customization parameters, for the transmission of messages. |
| B.4.10 | The vendor shall describe in detail the end-users enrollment/registration/login for the secure, encrypted, HIPAA-compliant use of the modernized messaging application as well as the enrollment/registration/login of GFE and BYOD smartphone devices to ensure non-enrolled personnel and non-enrolled devices do not have access to the solution. |
| B.4.10 | The SaaS solution shall provide the capability and functionality to administratively have messages escalation cascades rules, for individuals, roles, and groups, that set processing timings and workflows of messages based on the tag levels of priority, urgent and standard. |
| B.4.10 | The solution shall provide the capability and functionality to override application settings for priority and urgent message tag levels and deliver message on the devices as soon as they are received by the solution. |
| B.4.10 | The solution shall provide Hotlinking functionality, that is capable of embedding phone numbers in a message for initiating a call from the mobile device. |
| B.4.11 | MESSAGING SOFTWARE APLICATION NOTIFICATIONS AND ALERTS |
| B.4.11 | Provide a solution that has customizable notifications and alerts functionality. |
| B.4.11 | The solution shall have the capability and functionality to reply, and receive secure HIPAA compliant peer to peer texting, and document transmissions. |
| B.4.11 | The solution shall provide a near real-time notification/confirmation that messages are delivered, read, and received. |
| B.4.14 | MESSAGING SOFTWARE APPLICATION FUNCTIONAL PERFORMANCE |
| B.4.14 | The Contractor shall provide a messaging software application that meet the following specified standard set of key performance indicators (KPIs) that the Government will use to evaluate and measure the solutions effectiveness: |
• CONUS Wi-Fi Offloading and Handoff Availability (Service) (Av(S)) 99.95%
• Time to Restore (TTR) 4 hours
• Response Time (Messaging) (RT) 100 milliseconds
| B.4.14 | The solution shall provide isolation of messaging to only authenticated users. |
| B.4.14 | The solution shall provide enhanced class internet protocol service for critical non-life safety messaging traffic. |
| B.4.14 | The SaaS solution shall provide the ability to select and provision services as needed; provide broad network access to mobile devices; be location independent for users throughout the Government’s enterprise; the ability to rapidly scale up or down based on user peak and off-peak demands. |
| B.4.14 | The solution shall be responsive with instantaneous interactions from button pressing and toggle settings. |
D.2 Service Model Questions
| 36C10A25R0002 Attachment D.2 Service Model Questions | ||
| 1 | Brief Overview of (PRODUCT) and how the VA will use the product? | |
| 2 | Where is the SaaS hosted? (AWS, GCP, AZURE) | |
| 3 | How would VA users access the solution? (ex: web browser, mobile app) | |
| 4 | How would VA users authenticate? (ex: SSO integration, username/password) | |
| • | If user accounts are created, what does that process look like? | |
| • | If VA wished to add an additional user to be able to use the solution, how would that be accomplished? | |
| 5 | Would you consider (PRODUCT) Web architecture to be multi-tenant? (Is the information system architected in a multi-tenant manner where each customer has its own tenant, and all tenants share the same underlying architecture following the multi-tenant architecture definition) (Even if logically seperated) | |
| 6 | Is (PRODUCT) Web environment horizontally scalable to react to changes in demand or usage? If so, is the process fully automated or executable with minimal intervention? | |
| 7 | 10. Are any contractors/providers sourcing development activities from personnel that reside OCONUS? ** Yes or No. If Yes, please explain | |
| 8 | 11. Are any contractors/providers allowing access to a FedRAMP Boundary or Federal data to personnel that reside OCONUS? ** Yes or No. If Yes, please explain |
D.3 Step 2 Evaluation
| Techncial Step 2 - Written Step-by-Step Instructions for B.4.14 Software Application Capabilities and Effectiveness | |
| Use Case | Application Capabilities |
| B.14.14.1 Use Case A | Send a message to a peer (Escalation and Role-Based one-to-one relationship). Examples include: |
| • | Role based communication, such as “Cardiology Fellow” or “Critical Care Attending” | ||
| • | Trainee clinician (physician, PA or NP) to reach my supervising clinician (Physician, PA or NP) to provide updates and ask questions about patients' care | ||
| • | Bedside nurse to reach clinicians to ask routine order clarification questions. | ||
| • | Bedside nurse to summon a practitioner or security to the bedside | ||
| • | Bedside nurse to reach pharmacist for assistance with medication questions. | ||
| B.4.14.2 Use Case B | Send a message to a group (Escalation and Role-Based one-to-many relationship). Examples include: | ||
| • | Bedside nurse to request or summon other support professionals to the bedside (respiratory therapy, facility maintenance for electrical/plumbing, radiology tech, biomedical engineering, etc). | ||
| • | Operating room nurse or surgical technician to reach sterile processing or supply technicians for missing instruments or unexpected needs during a surgical case | ||
| • | Operating room circulating nurse to summon clinicians or groups to the operating room based on verbal requests of the surgeons & anesthesiologists | ||
| B.4.14.3 Use Case C | Contact a peer or group (Escalation and Role-Based) when I don't have a name of the person or group I need to contact/reach. Examples include: | ||
| • | Directory function with messaging application – needs to have a strong search function to help nurses find providers | ||
| • | Lab technician, pathologist, or radiologist communicate urgent results to the clinicians who is/are responsible for the patient during off-hours. | ||
| • | Allied health professional to reach the nurse taking care of a patient to provide information or ask questions regarding a patient. | ||
| • | Practitioner to reach other practitioners from different specialties to consult/ask for clinical advice. | ||
| • | Nurse working in the call center need to provide a warm hand-off to a practitioner with details about a patient that has been advised to walk-in to their clinic or emergent department by reaching clinicians across multiple VAMCs and sometimes in other VISNs | ||
| • | Escalation of messages if the intended recipient does not read/acknowledge receipt of message. Unanswered message will automatically be escalated to a backup team member within defined/customizable timeframes | ||
| B.4.14.4 Use Case D | Encounter inability to find on-call peers or groups (Escalation and Role-Based) due to outdated or missing on-call schedules. Potential solution discussion: Staff join (and leave) specific roles and are messaged based on their roles (of which they can have more than 1 simultaneously). For example, When Dr. Smith comes to work, she can manually join a role (such a “medicine admitting provider”). Then, when it’s time for someone to find whomever the doctor is that is admitting patients, there is no need to find a schedule or page a specific person, but instead they will always know to page “medicine admitting provider. Examples include: | ||
| • | Ability to create message templates for common activities to improve the quality of communication (i.e. code stroke, consults, abnormal labs) | ||
| • | Integrated directory – ability to see the organization’s entire directory and search by role/title/service/department/patient assignment. Unified, single view of who is on-call with one-click communication. Messages can be sent based on a needed service (i.e. housekeeping, chaplain, respiratory therapy). | ||
| B.4.14.5 Use Case E | Surrogate or Coverage – Need to be able to assign to someone else if someone is on leave or suddenly unable to cover calls. Examples include: | ||
| • | Patient care roles (i.e. Cardiology Fellow) – ability to claim roles by the end-user via the mobile application. Ability to determine which roles can be let empty, and which roles must have an always assigned staff member. | ||
| • | Patient care roles (charge nurse, on-call physician specialties, care managers etc) and in-house ancillary services (respiratory therapy, janitorial, radiology technician, chaplain, etc) must be easily claimed or assigned. Text messages can be sent based on a needed service or name of staff member. | ||
| • | End user (i.e. Cardiology Fellow) can place themselves on call or off call and complete this task within the mobile application, thus not have the task managed by a facility administrator/solution point of contact on a desktop version of the mobile application | ||
| B.4.14.6 Use Case F | Any clinical staff in a Medical Center needs to be able to reach out to other clinicians based on the following | ||
| • | Name, role that they're fulfilling, team (or group) in which to coordinate, and that's usually in an emergency setting | ||
| • | Message escalation – escalation of messages if the intended recipient does not read/acknowledge receipt of message. Unanswered message will automatically be escalated to a backup team member within defined/customizable timeframes | ||
| • | Message tracking/auditing – ability to track the status of individual messages and whether the user has received or read them. | ||
| • | Message priority – ability to mark messages as urgent/emergent with unique ringtones and delivery options. Priority rules to ensure they are read and responded to first (i.e. persistent alerts). |
File details come from the government source that posted it. Updated .