IHS-24-SS-1493807.pdf

Sources Sought- Adverse Events Reporting System: IHS-24-SS-1493807

Sources Sought Notice: Adverse Events Reporting System

MARKET RESEARCH PURPOSES ONLY

NOT A REQUEST FOR QUOTE, PROPOSAL OR SOLICITATION

The Indian Health Service (IHS) is conducting market research to support the IHS Office of Quality (OC) to secure a Commercially Available Off-the-Shelf (COTS) database that is FedRAMP certified or able to operate inside the IHS network incident reporting and investigation system that will support facility and field operations IHS-system-wide.

This is a Sources Sought notice to determine the availability of small businesses (inclusive of VOSB, SDVOSB, HUBZone SB, SDB, WOSB, LB), and Indian Economic Enterprises (IEE) and Indian Small Business Economic Enterprises (ISBEE) capable of supplying the required solution and support services.

This notice is for planning purposes only, and does not constitute an invitation for Bids, Request for Proposal or Request for Quotation or an indication the Government to award a contract, nor does the Government intend to pay for any information submitted as a result of this notice. Your responses to the information requested will assist the Government in determining the appropriate acquisition method, including whether a set-aside is possible.

I. Scope of Work:

This is a request for a Commercially Available Off-the-Shelf (COTS) database that is FedRAMP certified or able to operate inside the IHS network incident reporting and investigation system that will support facility and field operations IHS-system-wide. The COTS product should address patient-care-related and non-patient-care-related safety incidents. The COTS product will be modified as described in section 5.5. The system will be available for all federal, Tribal, and Urban Indian Health Programs IHS employees, be available 24 hours a day, 7 days a week to report incidents, and will be utilized at the national, regional, and local levels by approximately 800 patient-care related safety account holders and 400 non-patient-care related safety account holders to investigate incidents. The contractor should have technical experience or competency in the fields of patient safety, medication errors, occupational safety, physical security, and risk management.

Services include providing software necessary to implement the incident reporting system and providing technical support as required. The contractor shall accomplish system availability of at least 99 percent, meet Federal IT/Security/Accessibility requirements, and a help desk that shall have a toll-free number, email address, and instant chat; and be available 8 am to 8 pm Eastern Time, Monday through Friday.

II. Capabilities Sought

Core Capabilities Sought:

1.) The solution shall be commercial off the shelf, no development for the core system functionality is acceptable.

2.) Solution shall be FedRAMP approved (or capable of being approved prior to 12/15/2024) or able to operate within the IHS firewall.

Salient Characteristics Sought:

1.1 Solution Requirements: Capable contractor’s proposed solution shall be provided in one of two modes:

1.1.1. IHS-operated servers within the IHS network, the COTS product will be hosted in the

Albuquerque Data Center, in Albuquerque, NM, and must comply with all IHS and federal IT requirements to be hosted on the IHS network. The platform will contain Controlled Unclassified Information including Sensitive but Unclassified (SBU) and PII along with Personal Health Information. No classified information will be contained in these systems.

Federal Information Processing Standard (FIPS) 199 classification is High for Availability, High for Integrity, and High for confidentiality.

Or-

1.1.2. A FedRAMP-certified cloud implementation, in which the vendor shall provide all necessary support for the application, the selected product must meet Federal Risk and Authorization Management Program (FedRAMP) requirements or must be able to obtain FedRAMP compliance within 90 days. A compliant FedRAMP solution will consist of both a FedRAMP-approved cloud solution and a FedRAMP-approved application.

FedRAMP approval solely for a cloud hosting solution is insufficient for the purposes of this contract. This shall include:

1.1.2.1. Managing and maintaining web applications and web environments, as appropriate to the proposed technical solution.

1.1.2.2. Managing and maintaining application database, maintaining security and integrity controls, overseeing the scheduling of database projects, database and transaction log backups, notifications, and database replication, and maintaining and improving all Disaster Recovery plans to include backups, recovery, replication, design, configuration, performance tuning, testing and documentation yearly; as well as any other required activities to ensure database operations and integrity.

1.1.2.3. Implementing and supporting all routine monitoring of the web server infrastructure, critical services, and website issues; drafting and following established

Service Level Agreements within the service standards for service-level monitoring and other related alerts; and providing notifications to the Federal Manager and COR for all critical service impacts and outages.

1.1.2.4. Complying with further FedRAMP requirements listed in Appendix 1.

1.2. System Requirements:

1.2.1. Provide an application with a consistent style for navigation and presentation features for any participating federal, Tribal, or Urban Indian Health Programs IHS employee (User), to report an incident on a 24/7 basis. The acceptable availability shall be at least 99 percent.

1.2.2. Provide a common start page for all user types listed in section 5.4 of this performance work statement.

1.2.3. Provide electronic incident reporting capability using a mobile-friendly, web browser-based application compatible with the IHS-specified and most major web browsers that meet the following system specifications & capabilities:

1.2.3.1. At a minimum, the COTS solution shall provide individual and inter-related electronic incident reporting ability for each sub-type of patient-care related and non-patient-care related safety incident;

1.2.3.2. Capability to report patient-care-related safety incidents and non-patient-care-related safety incidents.

1.2.3.3. Patient injury incidents shall allow a reporter to choose to remain anonymous;

1.2.3.4. Provide functionality that allows for “enter once and populate forward” data entry;

1.2.3.5. Simple, intuitive user interface allowing the user to navigate and submit the minimally-required elements of patient-care-related safety incidents within 2-4 minutes;

1.2.3.6. Maximized mineable discrete data fields balanced with optional free text fields;

1.2.3.7. Provide functionality that allows users to initiate, enter data, save data and exit, and at a later time return to complete, amend, or update report;

1.2.3.8. Utilize intelligent pathways to minimize fields not applicable to user-defined incident characteristics;

1.2.3.9. Provide mouse-over tips and definitions, along with page-specific help, to assist users with the reporting process and to improve data accuracy for critical elements;

1.2.3.10. Occupational injury/illness reporting shall include at least the minimum data elements required for and allow management of reports in compliance with Occupational Safety and Health Administration (OSHA) recordkeeping requirements and consistent with the OSHA Incident Report sample forms 1 & 2, and the Bureau of Labor Statistics Survey of Occupational Injuries and Illnesses - Injury and Illness Case form. Occupational injury/illness reporting shall be consistent with the data elements listed on form HHS 841;

1.2.3.11. Occupational injury reporting shall capture all required elements to comply with the OSHA Bloodborne Pathogen Standard and Needlestick Prevention Standard consistent with the Model Plans and Programs for the OSHA Bloodborne Pathogens and Hazard Communications Standards;

1.2.3.12. Occupational injury reporting will capture at least the defined standard data elements utilized by, and provide an export format compatible with, the National Institute for Occupational Safety and Health (NIOSH) Occupational Health Safety Network (OHSN);

1.2.3.13. Property damage entries shall capture data elements consistent with GSA Form 3620 and SF 91;

1.2.3.14. Hazardous condition reporting shall capture at least the data elements consistent with DHHS form 834 - Report of an Unsafe Unhealthy Work Condition, Practice, or Hazard;

1.2.3.15. User and Account Holders shall be allowed to attach pictures, PDFs, and other common electronic files to any incident report;

1.2.3.16. Incident report forms shall be allowed to be printed in the same general layout as presented in the web browser-based application;

1.2.3.17. For OSHA recordable incidents, at the time of report submission, provide users a crosswalk of reported data and a link to use in completing separate reports within the Department of Labor Electronic Compensation Operations and Management Portal;

1.2.3.18. Patient safety incident reporting shall include at least the minimum data elements required for AHRQ Patient Safety Indicator PSI dashboard compliance; and

1.2.3.19. Incorporate AHRQ Common Formats, a standardized taxonomy (no-cost, publicly available taxonomy), and a systematic method for reporting adverse events, near misses, unsafe conditions, and harm from all causes.

1.2.3.20. Data elements for Individual Case Safety Reports to the FDA Adverse Events Reporting System and Forms FDA 3500, 3500A, and 3419 for Medical Device Reporting.

1.2.4. Provide user permission levels based on geographic locations and role as either Account Holder or Account Manager. All accounts will adhere to IHS/HHS user account security and maintenance standards. The account settings shall meet the requirements below:

1.2.4.1. Provide Account Holders the ability to review the names and account permissions of Account Holders and Account Managers for facilities for which they have permissions;

1.2.4.2. Notify users upon report submission regarding Account Holder(s) with permissions to review and investigate the report;

1.2.4.3. Notify individual incident reporting users upon completion of incident investigation, and provide feedback on results of investigation;

1.2.4.4. Generate email notifications regarding initial incident report submissions to Account Holders and Account Managers based on permissions and choice of notifications;

1.2.4.5. Allow Account Managers to modify email notification choices for themselves and the Account Holders in their region.

1.2.4.6. Provide an online account request process for new accounts or modifications, and generate automatic emails to account holders specifying changes to their account permissions;

1.2.4.7. Allow Account Holders with appropriate permissions to access incidents, verify or amend incident reports, and include investigation information;

1.2.4.8. Provide Account Holders the ability to search for individual incident reports;

1.2.4.9. Require that OSHA recordkeeping data elements must be completed before the incident investigation process is complete;

1.2.4.10. Allow Account Holders to select, monitor, trend, and report data by date range and/or facility/regional location(s);

1.2.4.11. Provide Account Holders a tracking system for all reported incidents and their status in real-time; and

1.2.4.12. Provide comprehensive data export functionality with parameters defined by the Account Holder and using plain language terminology.

1.3. System Performance Requirements

1.3.1. The system shall meet Federal IT/Security/Accessibility requirements.

1.3.2. It will be FedRAMP-certified or available to operate within the IHS network.

1.3.3. Data redundancy and backup shall include the capabilities listed below:

1.3.3.1. A unique identification number shall be generated for each incident;

1.3.3.2. Provide means to store and retrieve incident reports for a minimum of 30 years from the date of the incident.

1.3.4. Provide feedback submission capability for process improvement and change requests.

1.3.5. Performance level:

1.3.5.1. Page-to-page changes: 3 to 8 seconds; and

1.3.5.2. Pre-defined basic table/chart reports: 3 to 30 seconds.

1.3.6. To the maximum extent possible system software components are developed as self-contained modules that facilitate change or replacement.

1.3.7. Allow the maximum number of non-login users to enter incidents without degradation to system operation.

1.3.8. Allow the maximum number of login users to perform review and analysis on submitted incidents, produce reports, and/or create exports without system degradation.

1.4. Requirements for User Types for Patient-Care and Non-Patient-Care-Related Incidents:

1.4.1. Patient-Care-Related Incident and User Types

1.4.1.1. A patient-care-related incident shall be defined as one of the below and followed by the Agency for Healthcare Research and Quality (AHRQ) Common Formats in a layered scheme:

1.4.1.1.1. Errors or adverse events that have had or are expected to have a clinical effect on the patient. The effect is perceptible to either the patient or the healthcare team;

1.4.1.1.2. Errors or adverse events that necessitate a change in the patient’s care;

1.4.1.1.3. Errors or adverse events that cause temporary harm to the patient;

1.4.1.1.4. Errors or adverse events with a known risk of serious future health consequences, even if the likelihood of that risk is extremely small;

1.4.1.1.5. Errors or adverse events that require providing treatment or procedure without the patient’s consent;

1.4.1.1.6. Errors or adverse events that may have contributed to or resulted in permanent harm to the patient;

1.4.1.1.7. Errors or adverse events that required intervention to sustain life;

1.4.1.1.8. Errors or adverse events that may have contributed to or resulted in the patient’s death; and

1.4.1.1.9. Near misses in which an error or adverse event nearly reaches the patient but is identified and mitigated before reaching the patient.

1.4.1.2. System use will occur on five levels - users, account holders, regional account holders, regional account managers, and system account managers. The system access will be authenticated to each user type as prescribed below:

1.4.1.2.1. Users will be able to access the reporting functions without the need for a user account;

1.4.1.2.2. Account Holders, for a facility or subset of facilities, will be able to review, edit, and insert investigation data for incident reports as well as trend, analyze & export incident report data;

1.4.1.2.3. Regional Account Holders, for facilities within their region, will have the same capabilities as Account Holders;

1.4.1.2.4. Regional Account Managers will have the same capabilities as Regional Account Holders, and will be able to add/edit/delete Account Holders or Account Holder permissions for facilities that fall within their region; and

1.4.1.2.5. System Account Managers will have the same capabilities as Regional Account Managers and will be able to add/edit/delete Account Holders, Regional Account Holders/Managers, and establishments within their region(s).

1.4.1.3. Medication-related safety incident

1.4.1.3.1. A medication-related safety incident shall be defined as any preventable event that may cause or lead to inappropriate medication use or patient harm while the medication is in the control of the health care professional, patient, or consumer.

1.4.1.3.2. Medication error entry shall pull drug information from a database (accessible for modification by an IHS system account manager) that contains a complete list of available drugs, dosage forms, route of administration, dosage strength, generic name, trade name, therapeutic class, and container type.

1.4.1.3.3. The system shall classify medication errors based on the NCC MERP index for categorizing medication error algorithms. System users will have the ability to record a dissent of the auto-classification and justification of the dissent.

1.4.1.3.4. The system shall identify where in the process the error occurred including ordering/prescribing, transcribing and verifying, dispensing and delivering, administering, monitoring, and reporting.

1.4.1.3.5. The system shall allow querying/reporting medication errors by generic name, trade name, therapeutic class, medication error category, and process where an error occurred; or data shall be reported in a tabular format that allows data to be filtered and sorted based on those categories.

1.4.2. Non-Patient-Care Related Safety Incident and User Types

1.4.2.1. A non-patient-care-related safety incident shall be defined as one or more of the following:

1.4.2.1.1. Hazardous condition;

1.4.2.1.2. Physical security breach;

1.4.2.1.3. Near miss event (non-medical in nature);

1.4.2.1.4. Damage to property;

1.4.2.1.5. Exposure to hazard (biological, chemical, environmental, ergonomic, physical, and/or psychosocial) resulting in illness or injury to:

1.4.2.1.5.1. Employees, contractors, students, and volunteers;

1.4.2.1.5.2. Visitors; and

1.4.2.1.5.3. Patients- not related to patient care.

1.4.2.2. System use will occur on five levels - Users, Account Holders, Regional Account

Holders, Regional Account Managers, and System Account Managers. The system access will be authenticated to each user type as prescribed below:

1.4.2.2.1. Users will be able to access the reporting functions without the need for a user account;

1.4.2.2.2. Account Holders, for a facility or subset of facilities, will be able to review, edit, and insert investigation data for incident reports as well as trend, analyze & export incident report data;

1.4.2.2.3. Regional Account Holders, for facilities within their region, will have the same capabilities as Account Holders;

1.4.2.2.4. Regional Account Managers will be able to add/edit/delete Account

Holders or Account Holder permissions for facilities that fall within their region;

and

1.4.2.2.5. System Account Managers will be able to add/edit/delete Account Holders, Regional Account Holders/Managers, and establishments within their region(s).

1.5. Required customization, within the COTS product:

1.5.1. Importation to the maximum extent possible of all existing IHS Safety Tracking and

Response (I-STAR) system data related to the incident types listed.

1.5.2. Provide updates to required data elements based on revisions to relevant OSHA, DOL, DHHS, and GSA requirements as provided by IHS.

1.5.3. Establishments shall be identified using codes from the IHS coding system for Area, Service Unit, Tribe, Reservation, and Community. The IHS Standard Code Book may be viewed at http://www.ihs.gov/scb/index.cfm?module=disp_tablesSCB&newquery=1. Other IHS codes may be required and will be provided by IHS.

1.5.4. Sources shall be capable of providing a defined process for managing Change Control Board (CCB) activities including the methodologies that will be used when executing and implementing approved changes. Capable sources will be responsible for:

1.5.4.1. Organizing and maintaining accurate records of change requests and CCB decisions;

1.5.4.2. Organizing and conducting CCB meetings;

1.5.4.3. Notifying the IHS stakeholders, contracting representatives, and software sponsor of meetings; and

1.5.4.4. Providing IHS with detailed cost and time estimates for CCB-approved Change Requests.

1.6. Required system reporting capabilities:

1.6.1. OSHA 300 Log of Work-Related Injuries and Illnesses.

1.6.2. OSHA 300a Summary of Work-Related Injuries and Illnesses (complete with establishment information).

1.6.3. Sharps Injury Log.

1.6.4. AHRQ Patient Safety Indicators (PSI) dashboard.

1.6.5. Pre-defined aggregated informational reports.

1.6.6. Summary reports based on user-selected parameters.

1.6.7. Line listings (e.g. OSHA Line Listings).

1.6.8. Export to a format compatible with submission to NIOSH OHSN.

1.6.9. Comprehensive Incident Record Auditing logs for all stages of input, review, and account management.

1.6.10. Elective electronic submission of Individual Case Safety Reports to the FDA Adverse Events Reporting System and Forms FDA 3500, 3500A, and 3419 for Medical Device Reporting. In the event such reporting is not feasible, the system will generate a report configured similarly to the FDA forms that will facilitate manual reporting by the system user.

1.7. System Support and Maintenance

1.7.1. Respondents to this notice shall be capable of annually providing resources on user reporting, account holder functions, and account manager functions as described below:

1.7.1.1. Tutorials – develop resources for users and account holders on essential system functions that incorporate adult learning principles;

1.7.1.2. The contractor shall provide up to two live Webinars. Live webinars will be recorded, made 508 compliant, and made available to new account holders and account managers;

1.7.1.3. Where system changes make portions of the webinar or tutorial obsolete :

1.7.1.3.1. For changes that make the webinar or tutorial less than 30% obsolete, a disclosure and errata notice will be posted in conjunction with the webinar or tutorial to alert users, account holders, and managers before viewing.

1.7.1.3.2. For changes that make the webinar or tutorial webinar or tutorial 30% obsolete or more, the content will be revised in its entirety for further use.

1.7.2. Ensure error resolution as follows:

1.7.2.1. Issues that impact overall system usability shall be resolved within 8 hours of discovery; and

1.7.2.2. Issues that do not impact overall system usability but do impact system users shall be resolved within 72 hours of discovery.

1.7.3. System Restart, when needed, will take 5-10 minutes.

1.7.4. Database Recovery:

1.7.4.1. Restarting the database, when needed, shall not take more than 10 minutes;

1.7.4.2. Recovering lost data, when needed, shall not take more than 8 hours; and

1.7.4.3. Restarting from a backup copy of the database, when needed, shall not take more than 8 hours.

1.7.5. Have routine evaluations for system and data quality assurance.

1.7.6. Have routine system maintenance (hardware and software) provided by the contractor.

1.7.7. Provide notice a minimum of 24 hours before any action that will result in the system being inaccessible. An expected time of the system being back online will be included in the notice. Scheduled downtime will include routine software upgrades and routine system hardware or database maintenance.

1.7.8. Provide account holder and account manager support which includes the following items:

1.7.8.1. Manuals for managing and investigating incidents and accessing reporting options for account holders;

1.7.8.2. Administrator Manuals for account managers;

1.7.9. The COTS solution shall offer the ability to broadcast emails to system users.

1.7.10. A help desk shall have a toll-free number, email address, and instant chat; and be available 8 am to 8 pm Eastern Time, Monday through Friday.

III. Capability Statements:

Responses to this sources sought shall unequivocally demonstrate the respondent's capabilities to provide the services above. At a minimum, responses shall include the following:

1. Cover Page: Business name and bio, EIN number, business address, business website, business size status (i.e., SB, VOSB, SDVOSB, HUBZone SB, SDB, WOSB, LB IEE, or ISBEE), point of contact name, mailing address (if different from business address), phone number and email address. Provide this same information again if responding to provide a service offered by another firm.

2. Relevant Past Performance information inclusive of date of services, description, dollar value, client name, client address, client contact name, client point of contact mailing address (if different from that provided for client), client point of contact phone number, client point of contact email address, and name of company (to include DUNS number and size status) if not the respondent.

3. Descriptive literature, brochures, marketing material, etc. detailing the capabilities of the firm, product and their relevance to those sought so that the Government may make a determination that the firm is potentially capable if a future solicitation is released. Any submitted information must demonstrate that the requirements detailed in section II above can potentially be met. Any responses that are a restatement (copy/paste of this notice, only stating yes/affirmative to each salient characteristic sought) of the above, may be considered non-responsive and not considered further as a potential source.

IV. Response Instructions:

Interested parties shall respond with capability statements; no larger than 40 pages (not inclusive of the cover letter) via e-mail in PDF or Word format (links will not be accepted) before 2:00 PM Eastern Time on July 19th, 2024 to Christopher.McGucken@ihs.gov.

In your response, please use "IHS-24-SS-1493807” followed by your organizations name as the subject line.

Additionally, if your firm is an Indian Economic Enterprise (IEE) or Indian Small Business Economic Enterprise (ISBEE)- Please include a completed and signed copy of attached form “IHS IEE Form.pdf” with your response. This form will not be counted towards the total page limit.

Disclaimer and Important Notes: This notice does not obligate the Government to award a contract or otherwise pay for the information provided in response. The Government reserves the right to use information provided by respondents for any purpose deemed necessary and legally appropriate. Any organization responding to this notice should ensure that its response is complete and sufficiently detailed to allow the Government to determine the organization's qualifications to perform the work. Respondents are advised that the Government is under no obligation to acknowledge receipt of the information received or provide feedback to respondents with respect to any information submitted. After a review of the responses received, a pre‐solicitation synopsis and solicitation may be published in Federal Business Opportunities.

However, responses to this notice will not be considered adequate responses to a solicitation.

Confidentiality: No proprietary, classified, confidential, or sensitive information should be included in your response. The Government reserves the right to use any non‐proprietary technical information in any resultant solicitation(s).