A2-ATTM013.xlsx

XLSX spreadsheet 33 KB Posted Nov 18, 2025

Attached to: HEALTH AND WELFARE CRITICAL INCIDENT MAN
Solicitation number: 5400027650
Issued by: Richland County, South Carolina

About this file

Written by GovTribe AI · Nov 18, 2025

Summary of A2-ATTM013.xlsx Requirements Response

This is a Requirements Response Book for the Health and Welfare Critical Incident Management (HWCIM) system procured by South Carolina state agencies, specifically the South Carolina Department of Health and Human Services (SCDHHS) and South Carolina Department of Disabilities and Special Needs (SCDDSN). The document outlines 150 functional and non-functional requirements that the contractor's proposed solution must satisfy across incident management, workflow management, dashboard functionality, reporting, security, data retention, and operational support. The requirements span incident reporting capabilities including creation, editing, searching, and submission of incident reports based on agency, eligibility, waiver programs, and incident categorization; workflow management including configurable workflows, alerts, and notifications; integration with external systems such as MES Core for claims and participant data exchange using FHIR standards; help desk operations available Monday through Friday from 8:30 AM to 5:00 PM Eastern Time; and comprehensive reporting and dashboard functionality to support performance measurement and compliance with CMS standards.

The requirements mandate that offerors select one of three implementation approaches for each requirement: out-of-the-box functionality, implementation with configuration, or implementation requiring customization. The contractor must maintain compliance with state and federal data security requirements including MARS-E and HIPAA standards, conduct annual security and penetration testing, and maintain a Recovery Time Objective of eight hours and Recovery Point Objective of one hour for disaster recovery. The system must support a ten-year data retention period for incident reports with automatic purging capabilities and must operate with continuous availability except during approved maintenance windows. The contractor is required to develop comprehensive documentation, provide initial and ongoing user training, operate a help desk with ticket management capabilities and monthly metrics reporting, and work with agencies to produce dashboards, reports, and data outputs supporting CMS outcomes measurement and waiver performance tracking.

View the file

Other files

File	Type	Posted
A2-ATTM026.xlsx	XLSX spreadsheet	Nov 18, 2025
A2-Amendment.docx	DOCX document	Nov 18, 2025
ATTM004-PDF.pdf	PDF	Nov 18, 2025
Award Posting Extension.doc	DOC document	Nov 18, 2025
ATTCH005.docx	DOCX document	Nov 18, 2025
Attachments.zip	ZIP file	Nov 18, 2025
Public Library.zip	ZIP file	Nov 18, 2025

On GovTribe

Work with this file

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

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Requirements Response

ATTM 013 REQUIREMENTS RESPONSE BOOK

INSTRUCTIONS: Cells in Columns A, B, C, D, and E are locked. Offerors shall only edit cells in Columns F and G.

For each requirement, Offerors shall select whether the proposed solution meets the requirement out of the box, with configuration, or with customization, by selecting the appropriate option out of the drop-down list in Column F. Offerors shall only select one option for each requirement. Offerors may provide further explanation of their response for each requirement in Column G.

	Requirement ID#	Requirement Type	Requirement
Category	Requirement
Sub-Category	Requirement Description	Response	Response Explanation
	1	Functional	Incident Management	Incident Reporting	The system shall have the ability to create an incident report based on the agency, eligibility, waiver/other program, incident category, sub-category and sub-type.
	2	Functional	Incident Management	Incident Reporting	The system shall allow the user to edit existing incident report based on the incident status.
	3	Functional	Incident Management	Incident Reporting	The system shall allow the creation of an incident report for an existing participant.
	4	Functional	Incident Management	Incident Reporting	The system shall allow the user to view existing incident reports based on the incident status.
	5	Functional	Incident Management	Incident Reporting	The system shall have the ability to generate a unique incident report number based on the agency and incident category when creating a new incident report.
	6	Functional	Incident Management	Incident Reporting	The system shall have the ability to set the incident report status based on the agency, incident category, sub-category and sub-type.
	7	Functional	Incident Management	Incident Reporting	The system shall have the ability to search key data elements based on a search criteria. Example: Participants (Medicaid and Non-Medicaid), Providers.
	8	Functional	Incident Management	Incident Reporting	The system shall have the ability to validate participant, provider, and other related information when creating or updating an incident report. Example: Not all participants need to be enrolled in eligiblity, waiver program when creating an incident report.
	9	Functional	Incident Management	Incident Reporting	The system shall validate all data elements when creating or updating an incident report.
	10	Functional	Incident Management	Incident Reporting	The system shall allow the user to submit an incident report when all required fields are entered, and data validation is complete.
	11	Functional	Incident Management	Incident Reporting	The system shall have the ability to search incidents based on an input search criteria that include, but are not limited to, agency, incident category, sub-category, sub-type, participants, demographics, eligibility, waiver/other program, providers, date range and incident status.
	12	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to accept an incident report.
	13	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to return an incident report.
	14	Functional	Incident Management	Incident Reporting	The system shall allow authorize users to capture the reason for returning an incident report.
	15	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to reject an incident report.
	16	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to modify a final report.
	17	Functional	Incident Management	Incident Reporting	The system shall allow the user to save an unsubmitted incident report.
	18	Functional	Incident Management	Incident Reporting	The system shall allow the user to cancel an unsubmitted incident report.
	19	Functional	Incident Management	Incident Reporting	The system shall allow the user to submit an initial incident report.
	20	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to submit an electronic signature.
	21	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to assign a final report type based on the agency, participants location (example: ICF/IID facility), and suspected criminal activity.
	22	Functional	Incident Management	Incident Reporting	The system shall allow the user to submit a final incident report after the initial report is accepted.
	23	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to flag as additional information is pending for a resolved incident report.
	24	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to mark an incident report to be retained indefinitely.
	25	Functional	Incident Management	Incident Reporting	The system shall allow the user to identify an attachment with an associated tag name. Example: APS, Medicaid fraud control unit.
	26	Functional	Incident Management	Incident Reporting	The system shall allow the user to attach multiple non-editable files with related tag names to identify the attachments.
	27	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to make edits to an incident report that has not been accepted or resolved.
	28	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to identify when a primary incident category is a result of an incident associated with a secondary incident category. Example: Death resulting from ANE where Death is the primary incident and ANE is the secondary incident.
	29	Functional	Incident Management	Incident Reporting	The system shall have the ability to create incident reports based on configurable business rules including, but not limited to, agency, incident category, sub-category, sub-type, eligibility, waiver/other programs, and information captured in the existing systems.
	30	Functional	Incident Management	Incident Reporting	The system shall have the ability to capture secondary incident category, sub-category, and sub-type when a primary incident is a result of a secondary incident. Example: Death resulting from ANE where Death is the primary incident and ANE is the secondary incident.
	31	Functional	Incident Management	Incident Reporting	The system shall allow the user to input secondary incident category, sub-category, sub-type, and related data elements when a primary incident is identified as a result of a secondary incident. Example: Death resulting from ANE where Death is the primary incident and ANE is the secondary incident.
	32	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to add/update reinstatements, supplemental information, care coordination attempts, disposition information, procedural reviews for an incident report including, but not limited to, the information captured in the existing systems based on the agency, incident category, sub-category, sub-type, eligibility, and waiver/other program.
	33	Functional	Incident Management	Incident Reporting	The system shall allow the user to input data elements including, but not limited to, the information captured in the existing systems.
	34	Functional	Incident Management	Incident Reporting	The system shall have the ability to retain minimal required information such as demographics, incident summary, etc., when reclassifying the category of an incident report.
	35	Functional	Incident Management	Incident Reporting	The system shall allow the user to reclassify the category of an unresolved incident report.
	36	Functional	Incident Management	Incident Reporting	The system shall have the ability to set a due date based on the agency, incident category, sub-category, sub-type, report status and data element(s) combination.
	37	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to modify the due date of an incident report.
	38	Functional	Incident Management	Incident Reporting	The system shall have the ability to capture incident date and time for an incident report including but not limited to incident occurred, discovered, reported, created, and last updated.
	39	Functional	Incident Management	Incident Reporting	The system shall have the ability to define and maintain configurable workflows including, but not limited to reinstatements, supplemental information, care coordination attempts, disposition information, procedural reviews based on the agency, incident category, sub-category, sub-type, eligibility, and waiver/other program.
	40	Functional	Incident Management	Incident Reporting	The system shall have the ability to automatically initiate workflows when an incident report is added or updated including, but not limited to reinstatements, supplemental information, care coordination attempts, disposition information, procedural reviews based on the agency, incident category, sub-category, sub-type, eligibility, and waiver/other program.
	41	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to update due date, alert duration related to reinstatements, supplemental information, care coordination attempts, disposition information, procedural reviews for an incident report including, but not limited to the information captured in the existing systems based on the agency, incident category, sub-category, sub-type, and waiver/other program.
	42	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to capture the reason when a due date is modified.
	43	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to mark an incident report as confidential.
	44	Functional	Incident Management	Incident Reporting	The system shall have the ability to identify input data elements, to be marked as confidential, based on the agency, eligibility, waiver/other program, incident category, sub-category, sub-type, incident report, and user role.
	45	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to capture the reason for an incident report to be soft deleted.
	46	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to soft delete an unresolved incident report.
	47	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to reject or accept an addendum.
	48	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to capture the reason for adding or updating an addendum to an incident report.
	49	Functional	Workflow Management	Notifications	The system shall have the ability to automatically notify users in the form of an alert, an email notification when an addendum for an incident report is submitted, returned, or accepted. Example: Investigation report from an external agency.
	50	Functional	Incident Management	Incident Reporting	The system shall allow the user to add multiple addendums to a resolved incident report.
	51	Functional	Workflow Management	Workflow	The system shall have the ability to display the work queue of incident reports for a logged-in user, using pre-defined criteria.
	52	Functional	Workflow Management	Workflow	The system shall allow an authorized user to view an incident report from the work queue.
	53	Functional	Workflow Management	Workflow	The system shall have the ability to display alerts generated for the logged-in user.
	54	Functional	Workflow Management	Notifications	The system shall have the ability to automatically notify users in the form of an alert, an email notification when an incident report is returned.
	55	Functional	Workflow Management	Notifications	The system shall have the ability to automatically notify users in the form of an alert, an email notification when an incident report is added or updated.
	56	Functional	Workflow Management	Notifications	The system shall have the ability to automatically notify users in the form of an alert, an email notification including, but not limited to, when reinstatements, supplemental information, care coordination attempts, disposition information, procedural reviews, media attention information is added or updated based on the agency, incident category, sub-category, sub-type, and waiver/other program.
	57	Functional	Workflow Management	Notifications	The system shall have the ability to view an incident report upon selecting an alert by the logged-in user.
	58	Functional	Workflow Management	Notifications	The system shall have the ability to automatically turn-off an alert from the user work queue after the user action or system event is completed.
	59	Functional	Workflow Management	Notifications	The system shall have the ability to automatically notify users in the form of an alert, an email notification when a reinstatement request for an incident report is submitted, returned, or accepted.
	60	Functional	System Function	Audit	The system shall allow authorized users to view the audit history of an incident report.
	61	Functional	System Function	Audit	The system shall capture the audit history when modifications to an incident report occur.
	62	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to reassign a provider for an incident report.
	63	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to submit a reinstatement request for a staff member when no existing request is pending.
	64	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to approve or reject a reinstatement request for a staff member.
	65	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to capture the reason when rejecting a reinstatement request for a staff member.
	66	Functional	Incident Management	Incident Reporting	The system shall not allow the user to submit reinstatement requests for incident reports which include a secondary category.
	67	Functional	Incident Management	Incident Reporting	The system shall capture all data elements that are required to measure the outcomes defined by CMS and agencies.
	68	Functional	Incident Management	Incident Reporting	The system shall capture all data elements that are required to measure each waiver or other program performance defined by the agencies.
	69	Functional	Incident Management	Incident Reporting	The system shall capture all data elements that are required based on the Health & Welfare Assurance and Sub-assurances defined by Centers for Medicare & Medicaid Services (CMS).
	70	Functional	Incident Management	Incident Reporting	The system shall capture all data elements related to Critical Incident Management including, but not limited to, that are currently being used in the Phoenix system.
	71	Functional	Incident Management	Incident Reporting	The system shall capture all data elements related to Critical Incident Management including, but not limited to, that are currently being used in the Incident Management System (IMS).
	72	Functional	Dashboard	Dashboard	The system shall have the ability to display information in the form of a dashboard with various snippets of information, including but not limited to: existing dashboards that are currently being used by the agencies and information related to pending tasks, incident details, participant details, addendums, dispositions, workflow details, claims data match details, workload details, tracking, and trending details.
	73	Functional	Dashboard	Dashboard	The system shall allow authorized users to view details for each item displayed within the dashboard.
	74	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to capture the reason when marking an incident report to be retained indefinitely. Example: Associated with a legal case.
	75	Functional	Incident Management	Incident Reporting	The system shall identify potential incidents by querying claims from MES Core and comparing with incident reports for a participant based on configurable match criteria including, but not limited to, claim type, claim status, date range, and diagnosis codes.
	76	Non-Functional	System Function	Reference Data	The system shall have the ability to define addendum types to classify addendums.
	77	Non-Functional	System Function	Reference Data	The system shall have the ability to define attachment types to classify attachments.
	78	Non-Functional	System Function	Reference Data	The system shall have the ability to define and maintain reference code values that are required for an incident report. Examples include but are not limited to: Incident categories, sub-categories, sub-types, participants, providers, eligibility, waivers/other programs.
	79	Functional	Incident Management	Incident Reporting	The Contractor shall work with the agencies and identify the input data elements related to secondary category, subcategory, and sub-type when a primary incident is identified as a result of a secondary incident. Example: Death resulting from ANE where Death is the primary incident and ANE is the secondary incident.
	80	Non-Functional	Workflow Management	Workflow	The system shall have the ability to define and maintain configurable workflows based on including, but not limited to, agency, category, sub-category, sub-type, eligibility, waiver/other program, incident status, user action/system event, and user role combination.
	81	Non-Functional	Workflow Management	Workflow	The system shall have the ability to define and maintain users.
	82	Non-Functional	Workflow Management	Workflow	The system shall have the ability to define and maintain roles.
	83	Non-Functional	Workflow Management	Workflow	The system shall have the ability to define and maintain user actions.
	84	Non-Functional	Workflow Management	Workflow	The system shall have the ability to associate a user with user roles and user actions/system events based on the agency, incident category, sub-category, sub-type, eligibility, and waiver/other program.
	85	Non-Functional	Workflow Management	Workflow	The system shall have the ability to calculate incident activity durations using calendar days.
	86	Non-Functional	Workflow Management	Notifications	The system shall have the ability to define and maintain alerts and email notifications based on including, but not limited to agency, incident category, sub-category, sub-type, priority, frequency, due date/duration, data element(s), incident activity, user actions, system events, and user roles.
	87	Non-Functional	Workflow Management	Workflow	The system shall have the ability to define and maintain a configurable user role-based access control (RBAC) for system access. Examples include but are not limited to: Data access, visibility, page/panel/group/field level security, data masking.
	88	Non-Functional	Workflow Management	Workflow	The system shall have the ability to include alerts and email notifications steps when defining a workflow.
	89	Non-Functional	Workflow Management	Workflow	The system shall have the ability to automatically initiate and assign a workflow including, but not limited to, when incident status, reinstatements, supplemental information, care coordination attempts, procedural reviews, submit incident report, disposition information, and media attention is added or updated based on the agency, incident category, sub-category, sub-type, eligibility, and waiver/other program.
	90	Non-Functional	Workflow Management	Workflow	The system shall allow authorized users to view, download, and delete a file attached to an incident report.
	91	Non-Functional	Workflow Management	Workflow	The system shall have the ability to add or update a workflow definition without impacting the existing workflow steps, operations or activities.
	92	Non-Functional	Workflow Management	Notifications	The system shall have the ability to automatically generate an alert, an email notification to a workflow step, user role, user action or system event. Examples of user actions include but are not limited to: Investigation initiated, investigation completed, incident status updated, incident resolution, incident timeframe, addendums, reinstatements, media attention, disposition information, provider internal reviews, administration reviews, pending updates, report due date, assigned to an external agency, corrective actions.
	93	Non-Functional	Interfaces	Interfaces	The Contractor shall interface with MES Core to obtain claims data from MMIS using Fast Healthcare Interoperability Resources (FHIR) standards for the Claim resource.
	94	Non-Functional	Interfaces	Interfaces	The Contractor shall interface with MES Core to obtain participant data from MMIS, Phoenix and, Consumer Data Support System (CDSS). Example: Demographics, Address, Waivers/Other program details, Provider, Case details, Eligibility details, RSP, Authorized Representative and other related information.
	95	Non-Functional	Interfaces	Interfaces	The Contractor shall interface with MES Core to obtain Medicaid and Non-Medicaid participant data from MMIS, Phoenix, and Consumer Data Support System (CDSS) using Fast Healthcare Interoperability Resources (FHIR) standards for the Patient resource.
	96	Non-Functional	Interfaces	Interfaces	The Contractor shall interface with MES Core to obtain provider data from MMIS, Provider portal, Phoenix, and Consumer Data Support System (CDSS) using Fast Healthcare Interoperability Resources (FHIR) standards for the Organization resource and the Practitioner resource.
	97	Non-Functional	Interfaces	Interfaces	The Contractor shall interface with MES Core to provide Incident Management System data according to the file format and frequency approved by the agencies.
	98	Non-Functional	MES Core	MES Core	The system shall interface with MES Core to exchange SCDHHS-specific and SCDDSN-specific reference data via approved interface protocols which include: Representational State Transfer (REST) API, or file-based interface using SFTP.
	99	Non-Functional	MES Core	MES Core	The Contractor shall incorporate additional data elements needed for required data feeds by appending agencies'-approved elements to the approved standards and interface protocols for each feed.
	100	Non-Functional	Dashboard	Dashboard	The system shall allow authorized users to configure and display dashboards based on the agency and user role.
	101	Non-Functional	Help Desk	Help Desk	The Contractor shall operate a help desk accessible to users via telephone, email, and a website from 8:30 AM to 5:00 PM, Eastern Time (ET) Monday - Friday with the exception of state holidays.
	102	Non-Functional	Help Desk	Help Desk	The Contractor shall record all help desk requests in an electronic tool that supports reporting and ticket management.
	103	Non-Functional	Help Desk	Help Desk	The Contractor shall provide help desk options for providers, caregivers, and agency users.
	104	Non-Functional	Help Desk	Help Desk	The Contractor shall provide monthly metrics for help desk requests including, but not limited to, call lengths, average call length per month, number of abandoned calls, number of transferred calls, total calls received, total calls handled, total calls resolved.
	105	Non-Functional	Application Help	Application Help	The Contractor’s system shall have the ability to assist users with application help as a feature on all pages and screens for both data elements and business processes.
	106	Non-Functional	Application Help	Application Help	The Contractor’s system shall keep the help contents up to date when changes are made in the application.
	107	Non-Functional	Reports	Reports	The system shall have the capability to generate on-demand, real-time, daily, weekly, month-end, quarter-end, and year-end reports.
	108	Non-Functional	Reports	Reports	The Contractor shall work with the agencies to produce dashboards, reports, tracking and trending reports, and data outputs to support the measurement of CMS and State outcomes, waiver performance measures, and CMS Assurance and Sub-assurances.
	109	Non-Functional	Reports	Reports	The Contractor shall provide ad-hoc reports within agencies' requested timeframes.
	110	Non-Functional	Reports	Reports	The system shall have the ability to export the report output to various formats approved by the agencies. Example: CSV, PDF, Excel Spreadsheet etc.,
	111	Non-Functional	Reports	Reports	The system shall have the ability to generate various types of reports, tracking and trending reports including, but not limited to, that are currently being used by the agencies.
	112	Non-Functional	Reports	Reports	The system shall have multiple ways to export data including, but not limited to, downloading, printing, and converting to PDF.
	113	Non-Functional	Reports	Reports	The system shall produce dashboards, reports, and data outputs to support the measurement of SLAs.
	114	Non-Functional	Reports	Reports	The system shall allow authorized users to create, modify, and manage reports and queries, and groups of reports and queries, as well as share reports among users. Offeror’s solution shall include developing and delivering reports that are:

(1) Necessary for the proper operation of the system.

(2) Necessary for the proper conduct of Contractor's business operations duties.

(3) Required by the State Plan, State law or regulation, or are federally-required (to be determined during DDI phase).

(4) Required for CMS Certification of the system.

(5) Required for compliance reporting.

(6) Required to report on contract performance standards.

(7) Included in the baseline system.

(8) Otherwise included in Offeror's proposed system.

115	Non-Functional	Reports	Reports	The system shall have the ability to generate a report listing participants with incident details that are scheduled to be purged.
116	Non-Functional	Reports	Reports	The system shall have the ability to generate a report listing participants with incident details, including the reason, that are marked to be retained indefinitely.
117	Non-Functional	Operational Support	Operational Support	The system shall allow authorized users to submit add or update security access request for a user or user role(s). Example: Providers, caregivers, and agency users.
118	Non-Functional	Operational Support	Operational Support	The system shall protect documents using security protocols and methods documented by the Contractor and approved by the agencies prior to system go-live.
119	Non-Functional	Operational Support	Operational Support	In the event of disaster or other catastrophic loss, the system shall support a Recovery Time Objective (RTO) of 8 (eight) hours and a Recovery Point Objective (RPO) of 1 (one) hour.
120	Non-Functional	Security	Security	The system shall maintain compliance with state and federal data security requirements as outlined in the approved System Security Plan (Deliverable D-032).
121	Non-Functional	Security	Security	The system shall undergo security and penetration testing at least annually following an approved plan.
122	Non-Functional	Security	Security	The system shall undergo disaster recovery and business continuity testing at least annually following an approved plan.
123	Non-Functional	Security	Security	The Contractor shall develop and provide a SCDHHS currently adopted version of MARS-E and HIPAA compliant System Security Plan (SSP) which outlines the safeguards implemented to support the protection of government data.
124	Non-Functional	Security	Security	The Contractor shall maintain a secure system through continuous security monitoring, patching, and alignment to industry best practices with regards to security and privacy.
125	Non-Functional	Security	Security	The Contractor shall provide SCDHHS Office of Cybersecurity (OCS) all environments vulnerability scans per MARS-E requirements. This requirement includes third party programs connected to the SCDHHS enterprise.
126	Non-Functional	Security	Security	The Contractor shall document the methodology used to defend against, identify and respond to, and mitigate risk of any breach, loss, or unauthorized/improper access/use/disclosure of government data or information systems that support government data, to include notification of such to SCDHHS.
127	Non-Functional	Security	Security	The Contractor shall work with SCDHHS to execute any Plans of Actions & Milestones (POA&Ms) identified in the Independent Assessment of Security and Privacy Approach section.
128	Non-Functional	Data Retention	Data Retention	The system shall have the ability to retain an incident report with a data retention period of ten (10) calendar years from the incident report last updated date.
129	Non-Functional	Data Retention	Data Retention	The system shall have the ability to automatically purge an incident report after reaching the data retention period from the incident report last updated date if the incident report is not marked to be retained indefinitely.
130	Non-Functional	Documentation	Documentation	The Contractor shall maintain an up-to-date configuration baseline as well as functional, technical, and security documentation applicable to the Health and Welfare Critical Incident Management (HWCIM) solution.
131	Non-Functional	Training	Training	The Contractor must provide system users with initial and ongoing Health and Welfare Critical Incident Management (HWCIM) system training.
132	Non-Functional	Data Integrity	Data Integrity	The system shall ensure that all data stored, processed, and retrieved maintains 100% accuracy, consistency, and integrity throughout its lifecycle.
133	Non-Functional	Data transformations	Data transformations	The system shall support such data transformations as needed to transform data provided from source systems to make it consumable and useable by the Health and Welfare Critical Incident Management (HWCIM) system.
134	Non-Functional	Regulatory	Regulatory	The contractor shall, through both system and business operations, support the State in achieving the MITA 7 Standards and Conditions:

(1) Modularity Standard.

(2) MITA Condition.

(3) Industry Standards Condition.

(4) Leverage Condition.

(5) Business Results Condition.

(6) Reporting Condition.

(7) Interoperability Condition.

135	Non-Functional	Certification	Certification	The system shall provide CMS-mandated Streamlined Modular Certification KPI metrics data and Outcomes to support ORR, CR, and ongoing operational reporting for the duration of the contract.
136	Functional	Incident Management	Incident Reporting	The system shall have the ability to capture the agency name and contact details when an incident report is assigned to an external agency.
137	Non-Functional	Operational Support	Operational Support	The Contractor’s system shall be available to users at all times with the exception of agencies approved maintenance timeframes for production systems.
138	Non-Functional	Operational Support	Operational Support	The Contractor shall process a submitted security user or user role access request within two (2) business days.
139	Non-Functional	Incident Management	Reports	The system shall have the ability to generate various reports related to users in the system based on agency, date range, and other criteria. Example: Users with access status (active, in-active, locked, suspended, terminated), new users added, existing users updated, users with role-based access, incidents created, incidents updated, incidents soft deleted, etc.
140	Non-Functional	Incident Management	Incident Reporting	The system shall have the ability to retrieve participant, provider, and other related information such as demographics, eligibility, waivers/other programs, RSP etc., from MES Core and associate to a new or an existing incident report.
141	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to download an incident report in PDF format, including attachments.
142	Functional	Incident Management	Incident Reporting	The system shall allow authorized users to assign an incident report to external agencies, based on the agency, incident category, sub-category, sub-type, eligibility, and waiver/other program.
143	Functional	Incident Management	Incident Reporting	The system shall have the ability to automatically generate an alert, an email notification for authorized users to assign an incident report to external agencies based on the agency, incident category, subcategory, sub-type, and waiver/other program.
144	Functional	Incident Management	Incident Reporting	The system shall have the ability to automatically generate an alert, an email notification for authorized users when an incident is assigned to an external agency based on the agency, incident category, subcategory, sub-type, and waiver/other program.
145	Functional	Incident Management	Incident Reporting	The system shall have the ability to automatically generate an alert, an email notification for providers and agencies to submit results of their internal reviews based on the agency, incident category, subcategory, sub-type, waiver/other program, and provider.
146	Non-Functional	Incident Management	Incident Reporting	The system shall allow authorized users to securely send and receive encrypted emails. Example: APS, SLED, PRTF, Providers.
147	Non-Functional	Incident Management	Incident Reporting	The system shall allow a logged-in user to access emails, including that have been sent by and received to the system.
148	Non-Functional	Incident Management	Incident Reporting	The system shall allow authorized users to attach documents when sending an email.
149	Non-Functional	Incident Management	Incident Reporting	The system shall allow authorized users to download email(s), including the attachments.
150	Non-Functional	Incident Management	Incident Reporting	The system shall allow authorized users to set the priority to ‘High’ when sending an email.

Values

Response List

Out of the Box

Configuration

Customization

File details come from the government source that posted it. Updated Nov 18, 2025.