Appendix I - SI Builder Requirements Traceability Matrix - Amended 5-5-2025.xlsx
XLSX spreadsheet 88 KB Posted
- Attached to
- System Integrator Builder
- Solicitation number
- 856
- Issued by
- Idaho
About this file
Appendix I - SI Builder Requirements Traceability Matrix (Amended 5-5-2025)
This document is a requirements traceability matrix prepared by the Idaho Department of Health and Welfare (IDHW) for the System Integrator Builder contract opportunity. The matrix outlines 387 detailed technical and non-technical requirements that contractors must address when proposing solutions for the System Integration Hub (SI Hub). Requirements span nine major functional areas, including distributed debugging and data messaging formats (Section A.1), environment and infrastructure management (Section A.2), data storage and governance (Section A.3), data quality and automation agreements (Section A.4), documentation and deliverables (Section A.5), monitoring and operations (Section A.6), project management and staffing (Section A.7), testing and quality assurance (Section A.8), and file transfer and scheduling capabilities (Section A.9). For each requirement, contractors must select from nine response options indicating how they will meet it—through Azure Native Services, other commercial off-the-shelf software, custom code, hybrid approaches, third-party managed services, documented deliverables, personnel commitments, processes, or training and support. The document specifies that if any discrepancies exist between this matrix and the official requirement language in Appendix A of the RFP, contractors must respond based on Appendix A requirements. An amendment dated May 5, 2025, indicates this is an active procurement document subject to ongoing updates.
The matrix does not establish pricing terms, set-asides, incumbent information, or contract term details, as these elements are addressed in separate RFP documents and attachments. Contractors responding to this procurement must integrate their proposed solutions with the IDHW requirement repository in Azure DevOps, maintain configuration management through version-controlled systems, and comply with IDHW data governance policies. Requirements emphasize Azure cloud deployment on state-owned and licensed instances, integration with existing IDHW systems including the Idaho Medicaid Information, Data, and Analytics Suite (I-MIDAS), and comprehensive audit logging and security controls. The contractor must provide forty-two thousand blended modification pool hours during the Design, Development, and Implementation (DDI) phase and sixteen thousand annual modification pool hours during maintenance and operations, with specific timeframes and deliverable expectations outlined throughout the document's comprehensive requirement set.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Appendix M SITB RFP Demo Script Final Amended 5-5-2025.docx | DOCX document | |
| Appendix L SI Builder Contract Template - Amended 5-5-2025.docx | DOCX document | |
| Attachment 3 RFP 865 Modification and Exceptions.docx | DOCX document | |
| Appendix J - SI Hub Interface Inventory.docx | DOCX document | |
| Attachment 4 RFP 865 Cover Form Amended 25-5-2025.docx | DOCX document | |
| Appendix N - Example of Monthly Interface Volumes.docx | DOCX document | |
| Appendix D SI Builder Terms and Conditions - Amended 5-5-2025.docx | DOCX document | |
| Attachment 6 SI Builder Technical Questions - Amended 5-5-2025.docx | DOCX document | |
| Appendix K SA0019_TRA_Technical_Framework_Plan_v5 - Amended5-5-5-2025.pdf | ||
| Appendix 0 Insurance Requirements .docx | DOCX document | |
| RFP # 856 SI Builder Admin Doc - Amended 5-5-2025.docx | DOCX document | |
| Attachment 1 RFP 865 Pre-Proposal Conference.docx | DOCX document | |
| Attachment 2 RFP 865 Offeror Questions.docx | DOCX document | |
| Attachment 5 SI Builder Cost Proposal - Amended 5-5-2025.xlsx | XLSX spreadsheet |
Show all 14
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions Note: Appendix A contains the official requirement language for this RFP. Should there be a discrepancy in any requirement language between Appendix I - Requirement Traceability Matrix and Appendix A, responders must respond to how they will meet the requirement based on the language for the requirement in Appendix A.
Responders must respond to each requirement on the Requirements Tab by selecting one of the following options on how the Responder plans to meet the requirement:
- Yes - Azure Native Service (Technical)
- Yes - Other COTS or Saas software (Technical)
- Yes - Custom Code (Technical)
- Yes - Hybrid Approach (Technical)
- Yes - Third-Party Managed/Subcontracted (Technical)
- Yes - Documented Deliverable (Non-Technical)
- Yes - Personnel Commitment to Comply (Non-Technical)
- Yes - Process (Non-Technical)
- Yes - Training/Support (Non-Technical)
Requirements
| DevOps ID | Requirement # | ||
| from Appendix A | Requirement Description | How Vendor Will Meet Requirement | |
| 15927 | A.1.1 | The Contractor's solution must provide the necessary functionality and configuration to fully support distributed debugging based on the unique identifier assigned to each transaction by the Systems Integrator (SI) Hub. | |
| 15933 | A.1.2 | The Contractor’s solution must support, at minimum, the X12, National Information Exchange Model (NIEM), Extensible Markup Language (XML), Health Level 7 (HL7), Fast Healthcare Interoperability Resources (FHIR), National Council for Prescription Drug Programs (NCPDP), and JavaScript Object Notation (JSON) standard data messaging formats to ensure interoperability. Any additional proposed messaging formats must be approved by the ARB. | |
| 15934 | A.1.3 | The Contractor's solution must support transactions that require a Synchronous Request/Response service pattern. | |
| 15935 | A.1.4 | The Contractor's solution must support transactions that require an Asynchronous Request/Response service pattern. | |
| 15936 | A.1.5 | The Contractor's solution must support a publish subscribe service capability that allows modules to broadcast messages using policy-based criteria. | |
| 15938 | A.1.6 | The Contractor's solution must provide message queuing services that allow system administrators to create queues, alter existing queues, and control the operation of the queues. | |
| 15939 | A.1.7 | The Contractor's solution must validate all received data exchanged through the IDHW SI Hub as configured in the DQAA dashboard with IDHW Data Governance Policy Standards. | |
| 15957 | A.1.8 | The Contractor's solution must provide a Managed File Transfer (MFT) broker that requires only use of approved and configured protocols and restricts access to files and file transfers based on Identity and Access Management (IdAM) privileges. | |
| 15958 | A.1.9 | The Contractor's MFT solution must support the Secure File Transfer Protocol (SFTP) and Hypertext Transfer Protocol Secure (HTTPS) protocols. Any additional proposed messaging formats must be approved by the Architecture Review Board (ARB). | |
| 15959 | A.1.10 | The Contractor's solution must automate file transfer processes, including the detection and handling of file transfer failures that are possible to resolve without intervention. | |
| 15960 | A.1.11 | The Contractor's solution must support the ability to initiate resumption of file transfers at the point of interruption. | |
| 15961 | A.1.12 | The Contractor's solution must support scheduled file transfers based on the option of defining messaging or integration rules or by setting configurable triggers. It must support both time-based scheduling (e.g., daily, weekly) and event-based scheduling (e.g., file arrival, system events). | |
| 15962 | A.1.13 | The Contractor's solution must support file processing both prior to and after transmission, with capabilities to implement file compression and decompression and computing and validating cryptographic checksums. | |
| 15963 | A.1.14 | The Contractor's solution must support file processing extensibility through API based capabilities. | |
| 15972 | A.1.15 | The Contractor’s solution must support, at minimum, the Representational State Transfer (REST), Web Services Description Language (WSDL), WebSocket (WS-*), Simple Object Access Protocol (SOAP), JSON, XML, and EDI standard web services and specifications. Any additional proposed messaging formats must be approved by the ARB. | |
| 16033 | A.1.16 | The Contractor's solution must provide the capability to aggregate logs for effective management and analysis. | |
| 16034 | A.1.17 | The Contractor's solution must have the configurable ability to migrate log data to more cost-effective platform storage options (i.e. "standard", "infrequent", "deep") based upon configurable business rule driven criteria. | |
| 16035 | A.1.18 | The Contractor's solution must provide a centralized logging component that supports standardized and configurable storage, management, retrieval, and archiving of all generated SI Hub logs and transmitted module logs. | |
| 16036 | A.1.19 | The Contractor's solution must generate and retain logs of all SI Hub configuration settings changes. | |
| 16037 | A.1.20 | The Contractor's solution must have the configurable ability to import and query log data sent by MMIS modules to the SI platform at a frequency determined by the State. | |
| 16038 | A.1.21 | The Contractor's solution must have the configurable ability to proactively monitor for, import, and index the data of log files transmitted to the SI Hub by MMIS modules at a frequency determined by the State. | |
| 16039 | A.1.22 | The Contractor's solution must have the configurable capability to prioritize the processing of log files transmitted to the SI Hub by log file type. | |
| 16041 | A.1.23 | The Contractor's solution must support the following log fields for all incoming and outgoing transactions: transaction timestamp, transaction ID, transaction size, description of action, user, source IP address, destination IP address, port, and response status code for a duration specified by the State. | |
| 16043 | A.1.24 | The Contractor's solution must support the configurable ability to isolate and retain specific log data for legal holds or audits. | |
| 16044 | A.1.25 | The Contractor's solution must log all SI Hub Managed data requests to load data or to access data at rest in an audit trail, accounting for originating source and user, including any failed attempts or resulting errors. | |
| 16045 | A.1.26 | The Contractor's solution must log and archive all query activities that request to create, read, update, or delete SI Hub Managed data. | |
| 16046 | A.1.27 | The Contractor's solution must store the files and full audit log of MFT file transfer activity for a duration specified by the State, with configuration available to support extended retention in a State designated repository. | |
| 16047 | A.1.28 | The Contractor's solution must support the configurable ability to retain all SI Hub user activity audit log data for a duration specified by the State, with configuration available to support extended retention in a State designated repository. | |
| 16048 | A.1.29 | The Contractor's solution must support retrieval of raw user activity audit log files within twenty-four (24) hours of receipt of request from the State. | |
| 16050 | A.1.30 | The Contractor's solution must provide configurable automated processes that routinely check to see if each module integration point is operating as expected, with the frequency of such checks being configurable by the State. | |
| 16051 | A.1.31 | The Contractor's solution must provide the ability to send error response notification to all sending MMIS modules and supporting components, including the specific errors that were identified and whether the errors precluded loading and/or using the transmitted data. | |
| 16057 | A.1.32 | The Contractor's solution must include tools to monitor SI Hub performance metrics in all supported environments including capacity and CPU utilization, response time, resource availability, network efficiency and load balancing, memory utilization, application performance, and end-user responsiveness. | |
| 16060 | A.1.33 | The Contractor's solution must perform configurable rules-based Data Quality monitoring and exception reporting as determined by IDHW data governance policies. | |
| 16076 | A.1.34 | The Contractor's solution must support the definition, triggering, and sending of configurable user alerts for SI Hub and MMIS module performance, failure, and exceptions in a variety of formats including Short Message Service (SMS) text, email, and automated phone call. | |
| 16080 | A.1.35 | The Contractor's solution must support configurable restricted access and authorization to specific dashboards, dashboard views, and features through the SI Hub IdAM/SSO component. | |
| 16081 | A.1.36 | The Contractor's solution must calculate Key Performance Indicators (KPIs) based on imported log data sent by MMIS Modules that include at minimum transaction response time, resource availability, CPU utilization, network load, memory utilization, application performance, end-user experience transaction tracing, user monitoring, and any additional KPIs necessary to perform issue resolution analysis. | |
| 16082 | A.1.37 | The Contractor's solution must provide the configurable ability to send alerts to designated users or user groups when configured key performance indicators (KPIs) of a monitored module or component falls outside of configured parameters. | |
| 16083 | A.1.38 | The Contractor's solution must provide the configurable ability to display Key Performance Indicators (KPIs) and tracks MMIS module Service Level Agreements (SLAs) at a frequency determined by the State based on imported log data sent by MMIS modules to the SI Hub that have been designated by the State for active monitoring. | |
| 16084 | A.1.39 | The Contractor's solution must support the import and display of module vendor calculated KPIs and SLAs, certification outcome statuses, and business indicators that have been sent by MMIS Modules in log files to the SI Hub. | |
| 16085 | A.1.40 | The Contractor's solution must provide functionality to query and analyze historical data from SI Hub and MMIS vendor logs. | |
| 16086 | A.1.41 | The Contractor's solution must provide the ability for users to view, search, and filter raw log files (e.g., by date, transaction type, user/system). | |
| 16087 | A.1.42 | The Contractor's solution must log all SI Hub dashboard component access attempts and user activity through the SI Hub Centralized Logging component. | |
| 16088 | A.1.43 | The Contractor's solution must provide the configurable ability to send alerts to designated users or user groups when MFT transmission errors occur, when expected files are not received within expected time thresholds, or when any other errors or exceptions are identified. | |
| 16090 | A.1.44 | The Contractor's solution must provide the ability to view, search, and filter MFT audit log via the dashboard user interface. | |
| 16091 | A.1.45 | The Contractor must provide the ability to generate reports based on MFT activity. | |
| 16092 | A.1.46 | The Contractor's solution must provide "breadcrumb" style navigation on all drilldown or drill through pages and views to facilitate return by the user to higher level content. | |
| 16094 | A.1.47 | The Contractor's solution must support persistent hyperlink navigation to specific dashboard views and features. | |
| 16095 | A.1.48 | The Contractor's solution must provide functionality to display SI Hub platform performance metrics in a customizable dashboard. | |
| 16100 | A.1.49 | The Contractor's solution must support printing a properly formatted representation of all dashboard screens and views, including sections not displayed without scrolling. | |
| 16102 | A.1.50 | The Contractor's solution must provide an on-demand report listing historical integration availability errors for each module with filtering options that include hour, day, week, month, and year. | |
| 16103 | A.1.51 | The Contractor's solution must provide an on-demand report identifying historical data transmission errors. | |
| 16106 | A.1.52 | The Contractor's solution must provide a single unified dashboard experience as configured by the SI Hub SSO component to maintain a user's session under a single login. | |
| 16107 | A.1.53 | The Contractor's solution must provide a configurable notification message or page that displays when the system is unavailable for scheduled maintenance or unscheduled outages. | |
| 16108 | A.1.54 | The Contractor's solution must support the retention of user profile management and user preferences across sessions for dashboard views and features. | |
| 16109 | A.1.55 | The Contractor's solution must support the definition, retention, management, and sharing of user defined detail level and summary level queries, dashboards, and custom data list views where applicable. | |
| 16110 | A.1.56 | The Contractor's solution must support the definition, retention, management, and sharing of user defined “ad hoc” dashboard reports. | |
| 16136 | A.1.57 | The Contractor's solution must provide the configurable ability to display at a frequency determined by the State all module configuration settings and values that have been designated by the State for active monitoring. | |
| 16137 | A.1.58 | The Contractor's solution must provide the configurable ability to display at a frequency determined by the State at minimum the title, description, most recent or current status, start date and time, end date and time (if applicable), and execution frequency of all MMIS module jobs designated by the State for active monitoring. | |
| 16138 | A.1.59 | The Contractor's solution must provide the configurable ability to send alerts to designated users or user groups when scheduled batch processing errors occur, when batch run times exceed configurable thresholds, or when any other errors or exceptions are identified. | |
| 15926 | A.1.60 | The Contractor must collaborate with the System Integration Technical Advisory (SITA) vendor and IDHW to design, test, and implement all standard interfaces required by the approved scope of work. | |
| 15931 | A.1.61 | The Contractor must only implement or revise services within the solution when the IDHW Architecture Review Board (ARB) has approved the proposed Interface Control Specifications (ICS). | |
| 15941 | A.1.62 | The Contractor's solution must provide versioning of interface specifications (see DQAA) for services and message formats throughout their lifecycle. | |
| 15942 | A.1.63 | The Contractor must ensure that all System Integration Hub service endpoints are clearly defined with documented and published Application Programming Interfaces (APIs). | |
| 16307 | A.1.64 | The Contractor must store configurations in a version-controlled and auditable Configuration Management System. | |
| 16308 | A.1.65 | The Contractor must provide configuration management reports when IDHW approved changes are made in all IDHW SI Hub environments. | |
| 16316 | A.1.66 | The contractor must provide a fixed price for forty-two thousand (42,000) blended modification pool hours to be used for design, configuration, testing, coordination, and implementation work as part of DDI. | |
| 16317 | A.1.67 | The Contractor must coordinate with MMIS module vendor(s) and IDHW as part of all SI Hub Builder and MMIS module DDI phases to replicate the existing external interfaces as directed by IDHW and add any new interfaces identified during each module DDI phase to pass through the SI Hub rather than via point-to-point connections between modules. | |
| 16475 | A.1.68 | The contractor must facilitate requirements validation and design sessions with the State, SITA, PMO, and other impacted IDHW module contractors to identify and address gaps in their solution | |
| 16202 | A.1.69 | The Contractor must provide a solution that meets the minimum State, Federal and/or IDHW requirements for audit logging and retention. | |
| 16293 | A.2.1 | The Contractor must integrate any internal Requirements Management and Test Management tools with the IDHW requirement repository (currently Azure DevOps) environment to the greatest extent possible to keep Contractor and IDHW systems in sync without requiring manual entry. | |
| 16294 | A.2.2 | The Contractor's proposed solution must support configuration changes with minimal disruption to ongoing operations. | |
| 16295 | A.2.3 | The Contractor must implement automated tools and processes to package executables, configurations, and source code to be automatically promoted into environments based on a schedule and approval from the State. | |
| 16296 | A.2.4 | The Contractor must ensure at the time of Go-Live that software components of the IDHW SI Hub have major and minor versions released within the prior year. All software versions in use must be free of known security vulnerabilities and must be fully supported by the software component publisher. | |
| 16297 | A.2.5 | The Contractor must provide the following environments at minimum with the ability to provision, populate, and configure additional environments: |
1. Development
2. System Integrated Testing
3. User Acceptance Testing
4. Production
5. Performance Testing (not full-time in operations)
6. Training (not full-time in operations)
7. Conversion Testing (DDI Only)
8. Parallel Policy Testing (DDI Only)
| 16298 | A.2.6 | The Contractor must implement the SI Hub in a State-owned and licensed Azure cloud instance. |
| 16300 | A.2.7 | The Contractor must provide a stand-alone production environment that does not interact with or rely on any other test environment to meet the requirements of this contract. |
| 16301 | A.2.8 | The Contractor’s solution must leverage existing IDHW cloud hosting platforms and to host all azure services and third-party software licenses identified in Attachment 5 – Cost Proposal Cloud and Software where possible. Any third-party licenses purchased by the Contractor must be transferrable to IDHW at the end of the contract. |
| 16302 | A.2.9 | The Contractor must employ industry standard automated tool sets for each of the following scenarios at a minimum: |
| 16303 | A.2.10 | The Contractor must design data exchanges to minimize cloud data transfer costs incurred by IDHW between different tenants on the same cloud provider and between different cloud providers. | ||
| 16304 | A.2.11 | The Contractor's solution must be scalable, able to adapt to meet future growth including the ability to retain its performance levels when adding additional interface integrations, functions, and data. | ||
| 16305 | A.2.12 | The Contractor's solution must utilize architectures with no single point of failure, supporting fault tolerance and failover of web, application, database, storage, and secondary devices. | ||
| 16306 | A.2.13 | The Contractor's solution must be highly configurable with minimal to no reliance on coded functionality to support future potential enhancements. | ||
| 16389 | A.2.14 | Prior to implementing updates to tools from software publishers and Cloud Service Providers, the contractor must provide IDHW with an impact assessment based on testing, release notes, and other available resources. | ||
| 16390 | A.2.15 | The contractor must ensure that platform utilization and billing reports from the SI Hub Cloud Service Provider(s) is available to IDHW. | ||
| 15943 | A.2.16 | The Contractor's solution must support the exchange of information for entities both inside and outside the Agency's Enterprise systems. | ||
| 15944 | A.2.17 | The Contractor's solution must support a stateless flow of information across services and between modules. | ||
| 15945 | A.2.18 | The Contractor solutions publish/subscribe service capability must support integration across multiple hosting platforms, including both cloud and on-premises, to send messages or transactions originating from one system/record to subscribers using policy-based criteria. | ||
| 15946 | A.2.19 | The Contractor's solution must support the capability to perform configurable rules-based data transformation and translation of interface transactions from one supported messaging format into another supported messaging format. | ||
| 15947 | A.2.20 | The Contractor's solution must support the capability to send messages that trigger a file transfer, based on file transfer events, to Commercial-Off-The-Shelf (COTS) managed file transfer tools. | ||
| 15948 | A.2.21 | The Contractor's solution must perform real-time integration between the IDHW SI Hub and the I-MIDAS to retrieve and apply data governance rules when validating interface transactions. | ||
| 15949 | A.2.22 | The Contractor must provide a configurable solution that integrates the Enterprise Service Bus (ESB) component with the Managed File Transfer (MFT)component to invoke business processes and send messages based on file transfer events. | ||
| 15964 | A.2.23 | The Contractor's solution must provide the capability to transfer files to both internal and external destinations. | ||
| 15965 | A.2.24 | The Contractor's solution must support secure integration with SI Hub Application Programming Interface (API)s to provide MFT endpoints. | ||
| 15966 | A.2.25 | The Contractor's solution must support configurable rules-based data translation of interface transactions from one data format into another. | ||
| 16040 | A.2.26 | The Contractor's solution must generate and maintain comprehensive security, performance, error/exception, data transformation, and transaction sequence logs for all interfaces. | ||
| 16042 | A.2.27 | The Contractor's solution must support the configurable ability to accept and store transmitted MMIS module log data for a duration specified by the State. | ||
| 15967 | A.2.28 | The Contractor's solution must have the ability to ensure that transmitted files adhere to the interface specifications as entered into the DQAA dashboard and approved by the ARB and DGRB. | ||
| 16602 | A.2.29 | The SI Hub must leverage the native capabilities of the selected cloud platform to ensure optimal performance and cost efficiency. | ||
| 16604 | A.2.30 | The Contractor's solution must be able to support data integrations between IDHW MMIS modules and exchanges with IDHW-authorized third-party systems. | ||
| 16606 | A.2.31 | The contractor's solution must make all platform monitoring data and metadata available to I-MIDAS. | ||
| 16607 | A.2.32 | The contractor's solution must make performance alert contents, history, and metadata available to I-MIDAS. | ||
| 16609 | A.2.33 | The SI Builder Vendor must select an SSO system that can leverage the State's active directory as the single identity source and fully support the integration of MMIS modules to provide a unified user experience. | ||
| 16611 | A.2.34 | The contractor's solution must support data-driven configuration of each log type including, but not limited to, storage location, file storage category, and retention period. | ||
| 16613 | A.2.35 | The contractor's solution must support the configuration of log data to be migrated to more cost-effective and long-term storage as determined by the IDHW. | ||
| 16618 | A.2.36 | The SI Hub design and implemented solution must consider the market environment, previous SI contracts and lessons learned from other states, and leverage existing capabilities where applicable. | ||
| 16619 | A.2.37 | The SI Hub design must comply with all existing applicable State and Federal policies and be comprised of components with the flexibility to meet new and emerging policies, including through no-cost vendor product enhancements where possible. | ||
| 16621 | A.2.38 | SI Hub must be designed to support each transition stage without creating a hard dependency on other project workstreams. | ||
| 16427 | A.2.39 | The contractor must convert all required data from existing data sources into the contractor's solution in a format that supports all IDHW-defined business processes as approved by IDHW. | ||
| 15923 | A.2.40 | The Contractor's solution must provide a gateway to act as an Application Programming Interface (API) front-end, receive API requests, enable throttling, caching, and security policies, pass requests to the back-end service, and then pass the response back to the requester. | ||
| 15924 | A.2.41 | The Contractor's solution must provide an interface broker that routes messages between different services and systems and properly determines the destination for all outbound transactions as defined through rules enabled configuration. | ||
| 15925 | A.2.42 | The Contractor's solution must restrict access to interfaces based on Identity and Access Management (IdAM) privileges. | ||
| 15928 | A.2.43 | The Contractor's solution must support configurable rules-based scheduling, sequencing, initiation, and validation of interface transactions. | ||
| 15929 | A.2.44 | The Contractor's solution must designate a unique identifier for all received interface requests. | ||
| 15930 | A.2.45 | The Contractor's solution must enforce use of only IDHW Architecture Review Board (ARB) and Data Governance Review Board approved Interface Control Specifications (ICS) as entered and approved into the DQAA dashboard, including but not limited to ports, protocol(s), data formats, and service descriptions for all integrations. | ||
| 15932 | A.2.46 | The Contractor's solution must support, at minimum, secure interface connectivity using the Secure File Transfer Protocol (SFTP), Hypertext Transfer Protocol Secure (HTTPS), Applicability Statement 2 (AS2), and Applicability Statement 3 (AS3) protocols. Any additional proposed protocols must be approved by the ARB. | ||
| 15937 | A.2.47 | The Contractor's solution must support transactions that require composite interface services, where a single API transaction may be coordinated to manage one or more additional API transactions as part of the overall composite transaction. | ||
| 15940 | A.2.48 | The Contractor's solution must support up to two concurrent API interface versions as may be required by IDHW. | ||
| 16073 | A.2.49 | The Contractor's solution must provide a dashboard user interface that is fully compatible with HTML 5. | ||
| 16074 | A.2.50 | The Contractor's solution must comply with all IDHW User Experience/User Interface Standards specified in the TRA. | ||
| 16318 | A.2.51 | The Contractor must work with the SITA team and IDHW Architecture Review Board (ARB) to consolidate existing interfaces into reusable integrations or services where appropriate to reduce duplication. | ||
| 16956 | A.2.52 | The Contractor's solution must support MFT transactions that require composite interface services, where a single transaction may be part of two or more additional interfaces as part of the overall composite transaction. | ||
| 16895 | A.2.53 | The Contractor's solution must provide the ability to view raw daily interface files for up to sixty (60) calendar days. Contractor must archive raw daily interface files after sixty (60) calendar days and maintain for a minimum of ten (10) years or longer if required by current Federal or State retention requirements. | ||
| 15993 | A.3.1 | The Contractor's solution must comply with ACID (Atomicity, Consistency, Isolation, and Durability) transaction design patterns. | ||
| 15994 | A.3.2 | The Contractor's solution must provide data storage/retrieval capabilities, including optimized data compression, data encryption, fine grained data masking, data redaction, data obfuscation, flexible data partitioning, and support data federation and data virtualization. | ||
| 15997 | A.3.3 | The Contractor's solution must support job scheduling through connection to industry standard tools (including job prioritization), and ad-hoc job requests. | ||
| 15998 | A.3.4 | The Contractor’s solution must support relational database design structures and star/snowflake schemas. | ||
| 16000 | A.3.5 Requirement Removed | The Contractor’s solution must allow dashboards to query the Idaho Medicaid Information, Data, and Analytics Suite (I-MIDAS) to display all required dashboard views. | ||
| 16001 | A.3.6 | The Contractor’s solution must provide access to SI Hub history of Gateway transactions and Managed File Transfers (MFT) to IDHW authorized modules and systems. | ||
| 16003 | A.3.7 | The Contractor’s solution must include monitoring tools for data quality, performance, usage patterns, error handling, logging, and identification. | ||
| 16029 | A.3.8 | The Contractor’s solution must support the calculation and storage of Key Performance indicators (KPIs) for Service Level Agreements (SLAs). | ||
| 15992 | A.3.9 | The Contractor’s solution must support scaling/sizing (up and down) based on usage, storage space, reporting, analytics, and ongoing integrations. | ||
| 15995 | A.3.10 | The Contractor's solution must support changing technology and regulations by using only standard-based, technology agnostic services, tools, and components. | ||
| 16005 | A.3.11 | The Contractor's solution must provide the ability to share and federate data among data sharing partners, third parties, and internal/external systems. | ||
| 16007 | A.3.12 | The Contractor's solution must support the integration, validation, association, and storage of structured, semi-structured, and unstructured formats of source data including flat files, .csv files, JSON, XML, and predefined file formats including fixed length file, and delimited. | ||
| 16008 | A.3.13 | The Contractor's solution must support the exchange of data via batches, web-services, queues, APIs, and other common exchange protocols. | ||
| 16010 | A.3.14 | The Contractor’s solution must have the capability to support SQL access, IDHW’s leveraged Business Intelligence (BI) tools (currently Tableau). | ||
| 16011 | A.3.15 | The Contractor’s solution must provide base platform support to the Idaho Medicaid Information, Data, and Analytics Suite (I-MIDAS) including but not limited to Azure infrastructure, Azure infrastructure security, Azure networking, logging and alerts and/or notifications, data access for analytics and reporting, and documentation. | ||
| 16012 | A.3.16 | The Contractor's solution must allow I-MIDAS to have read only access to necessary SI Hub data when required to support reporting, analytics, and IDHW business outcomes. Read only access may consist of a variety of different data access patterns based on IDHW’s requirements, potentially including direct access. Data can include but is not limited to interface data, performance metrics, SI Hub operations, logging, data quality, and governance. | ||
| 16014 | A.3.17 | The Contractor's solution must support the creation of statistical models and queries through database tools (e.g. Python, SQL, Snowflake), statistical tools (e.g. R), and visualization tools (e.g. Tableau, Power BI). | ||
| 16015 | A.3.18 | The Contractor's solution must support Structured Query Language (SQL). | ||
| 16030 | A.3.19 | The Contractor’s solution must optimize the indexes or table structures to benefit query performance. | ||
| 16031 | A.3.20 | The Contractor’s solution must define scheduled tasks to optimize, back up, and manage the underlying solution data. | ||
| 16023 | A.3.21 | The Contractor's solution must optimize and consolidate data storage to benefit performance, including read operations, complex queries, and business intelligence analytics. | ||
| 15971 | A.3.22 | The Contractor's solution must conform to and support compliance with all IDHW data policies and Federal, State, and Organizational regulations, including data quality, data governance, and security. | ||
| 15974 | A.3.23 | The Contractor's solution must include database auditing tools and the ability to review audit data as required by IDHW, State, and Federal regulations. | ||
| 15973 | A.3.24 | The Contractor's solution must align with the CMS Medicaid Information Technology Architecture (MITA) framework. | ||
| 15978 | A.3.25 | The Contractor's solution must support the capability to store data stored in active, infrequent, and archive structures. | ||
| 15990 | A.3.26 | The Contractor's solution must support configurable scheduling, sequencing, initiation, and validation of data management tasks. | ||
| 15991 | A.3.27 | The Contractor’s solution must store data, for a configurable retention period, in its original format for historical/auditing purposes. | ||
| 15980 | A.3.28 | The Contractor's solution must include tools to support an interface repository. | ||
| 15986 | A.3.29 | The Contractor's solution must support data quality management functionality based on automated and user-defined quality control capabilities, through near real-time accuracy, historic consistency, and scheduled updates. | ||
| 15977 | A.3.30 | The Contractor's solution must support and comply with data governance, including accountability, documentation and enforcement of data governance policies and procedures, and compliance auditing. | ||
| 15988 | A.3.31 | The Contractor must document, manage, and enforce compliance with Master Data Management (MDM) standards, policies, and procedures. | ||
| 15996 | A.3.32 | The Contractor must be responsible for defining capacity planning procedures and associated documentation to standardize the approach for solution capacity management as approved by the department. | ||
| 15979 | A.3.33 | The Contractor's solution must support the capability to archive of data and the ability to retrieve it based on rules driven functionality. | ||
| 15981 | A.3.34 | The Contractor's solution must assign standardized, unique, internal identifiers for data rows. | ||
| 15982 | A.3.35 | The Contractor's solution must prevent the unauthorized purging of data, such that the data is no longer recoverable or useable in accordance with policies. | ||
| 15983 | A.3.36 | The Contractor's solution must document, manage, and enforce compliance with data transformation functions, including but not limited to data-type conversion, data reformatting, data manipulation, string handling, lookups, regular expressions, calculations, derivations, and aggregation. | ||
| 15984 | A.3.37 | The Contractor's solution must ensure data accuracy through referential integrity of key identifiers, transformation compliance, and data governance compliance | ||
| 15985 | A.3.38 | The Contractor's solution must provide a metadata management tool that supports the ability to capture and analyze metadata from a broad range of sources including but not limited to data lineage, source system identification, timestamps, and user/system logging. | ||
| 15987 | A.3.39 | The Contractor's solution must support data cleansing functionality capable of detecting and correcting (updates and deletes) errors, duplicates, and inaccurate or malformed data based on IDHW business rules. | ||
| 15989 | A.3.40 | The Contractor's solution must support configurable rules-based functionality to document, manage, and enforce compliance. | ||
| 16016 | A.3.41 | The Contractor’s solution must support scheduled execution of data requests and processing of resulting responses across established integrations with MMIS modules and Third Parties. | ||
| 16017 | A.3.42 | The Contractor’s solution must optimize all data at rest. | ||
| 16018 | A.3.43 | The Contractor’s solution must allow the management of data timespans and relevance, including support for daily snapshots and periodic archiving. | ||
| 16019 | A.3.44 | The Contractor’s solution must be able to access SI Hub platform capacity monitoring data and the resulting analysis in the form of KPIs, transaction history, logging, metadata, and any additional information required to support dashboard-based analysis and review. | ||
| 16022 | A.3.45 | The Contractor’s solution must be able to access SI Hub platform capacity monitoring data and the resulting analysis in the form of KPIs, transaction history, logging, metadata, and any additional information required to support dashboard-based analysis and review. | ||
| 16025 | A.3.46 | The Contractor’s solution must incorporate security role-based data filters as approved by the department, at the user, field, and table level. | ||
| 16026 | A.3.47 | The Contractor's solution must provide configurable encryption management that supports integration with AWS, Azure, GCP, or third-party vendors. | ||
| 16027 | A.3.48 | The Contractor’s solution shall provide the capability to access all user activity including Single Sign On (SSO) and Identity Access Management (IdAM) log entries. | ||
| 16028 | A.3.49 | The Contractor’s solution must manage sensitive data, including Protected Health Information (PHI) and Personally Identifiable Information (PII), including the ability to prevent unauthorized use, distribution, or access, the ability to allow authorized access, and data masking where applicable. | ||
| 16024 | A.3.50 | The Contractor must procure, operate, and maintain a data sharing agreement tool that supports sharing, management, and stewardship of data. | ||
| 16004 | A.3.51 | The Contractor shall maintain all design related documentation reflecting the current solution data architecture, including ERDs, conceptual, logical, and physical data models, source-to-target maps, and any other required design artifacts supporting policies and procedures to promote data documentation, development, and management of defined data entities, attributes, and relationships. | ||
| 16058 | A.3.52 | The Contractor's solution must have the configurability to determine whether to manually or automatically terminate run-away/long-running queries or processes based on alerts and expected run-time thresholds. | ||
| 16547 | A.4.1 | The Contractor's proposed solution must have the capability to validate incoming data files against predefined schema specifications, including but not limited to data types, formats, constraints, and relationships. The extent of the validation must be driven by metadata/configuration as entered in the DQAA dashboard with IDHW Data Governance Policy Standards. | ||
| 16548 | A.4.2 | The Contractor's proposed solution must have the capability to reject any data files that do not comply with the defined schema if configured to do so and notify the appropriate people/systems of the specific issues. | ||
| 16549 | A.4.3 | The Contractor's proposed solution must have the capability to support versioning of data quality and automation metadata, ensuring each version is tracked and managed for change control, audit and reference. | ||
| 16551 | A.4.4 | The Contractor's proposed solution must have the capability to validate incoming data against all predefined validation rules, such as data type checks, range constraints, uniqueness, and business-specific logic. | ||
| 16552 | A.4.5 | The Contractor's proposed solution must have the capability to provide feedback on validation results, including errors, warnings, and success messages to data producers. The feedback must include the rules failed along with the natural key of the first ten (10) records that failed the rule for that data load. | ||
| 16553 | A.4.6 | The Contractor's proposed solution must have the capability to display the ownership of each data quality and automation agreements, all its associated data file attributes and configuration and processing history, including producers and consumers. | ||
| 16554 | A.4.7 | The Contractor's proposed solution must have the capability to track and log all metadata/configuration data changes attempted or made. Changes to be tracked and logged include but are not limited to schema, natural key of data; data owner; effective dates; data validation errors; notification history; file processing outcome including rejections, quarantines, or loads. | ||
| 16555 | A.4.8 | The Contractor's proposed solution must enforce data service agreements for data delivery frequency, latency, retention period, data quality metrics, and availability. Enforcement includes the capability to notify and perform pre-defined actions configured in the dashboard by data governance team when agreements are applied, including but not limited to rejections, quarantines, loads and notifications. | ||
| 16559 | A.4.9 | The Contractor's proposed solution must have the capability to make data quality and automation agreements publicly accessible to all relevant stakeholders as defined by IDHW. | ||
| 16561 | A.4.10 | The Contractor's proposed solution must have the capability to detect duplicate data files based on unique identifiers, checksums, file names, or metadata. | ||
| 16562 | A.4.11 | The Contractor's proposed solution must have the capability to handle detected duplicates according to predefined policies (e.g., reject, log, or notify) and trigger appropriate actions. | ||
| 16563 | A.4.12 | The Contractor's proposed solution must have the capability to identify replacement data files using parameters including version numbers, timestamps, and specific metadata flags. | ||
| 16564 | A.4.13 | The Contractor's proposed solution must have the capability to ensure that replacement data files are correctly processed, overwriting or archiving the original data and notifying dependent systems as necessary. | ||
| 16565 | A.4.14 | The Contractor's proposed solution must have the capability to provide a feedback mechanism for data consumers to report data quality issues, request changes, or suggest improvements. | ||
| 16566 | A.4.15 | The Contractor's proposed solution must have the capability to allow data producers to respond to feedback and iteratively improve the data quality and automation agreement adherence. | ||
| 16567 | A.4.16 | The Contractor's proposed solution must have the capability to automatically test and validate data against data quality and automation agreement specifications during ingestion and processing | ||
| 16568 | A.4.17 | The Contractor's proposed solution must have the capability to support automated regression testing when data quality and automation agreement changes to ensure ongoing compliance. | ||
| 16569 | A.4.18 | The Contractor's proposed solution must have the capability to continuously monitor data quality and automation adherence in real-time. | ||
| 16570 | A.4.19 | The Contractor's proposed solution must have the capability to generate alerts for any detected anomalies, breaches, or data quality and automation violations and notify relevant stakeholders. | ||
| 16571 | A.4.20 | The Contractor's proposed solution must have the capability to integrate with CI/CD pipelines to implement data quality and automation and schema changes during deployment. | ||
| 16572 | A.4.21 | The Contractor's proposed solution must have the capability to automatically trigger tests and validations upon data quality and automation agreement changes to ensure that data flows remain compliant. | ||
| 16573 | A.4.22 | The Contractor's proposed solution must have the capability to maintain a complete log of all data quality and automation agreement violations, changes, and accesses. | ||
| 16574 | A.4.23 | The Contractor's proposed solution must have the capability to ensure that logs are auditable, providing a record for compliance and governance purposes. | ||
| 16575 | A.4.24 | The Contractor's proposed solution must have the capability to have clear error-handling mechanisms for managing errors, and data quality and automation violations. | ||
| 16576 | A.4.25 | The Contractor's proposed solution must have the capability to support automatic correction, retries, and stakeholder notifications in case of errors or failures. | ||
| 16577 | A.4.26 | The Contractor's proposed solution must have the capability to implement a controlled change management process for any updates to data quality and automation agreements, provide effective dates for implementation, provide a mechanism to mark the data quality and automation agreement as approved, and a way to soft delete a data quality and automation agreement with an audit trail of what changed and by whom. | ||
| 16578 | A.4.27 | The Contractor's proposed solution must have the capability to ensure that any changes to data quality and automation agreements are documented and communicated effectively to all relevant parties defined in the data and quality and automation agreement. | ||
| 16579 | A.4.28 | The Contractor's proposed solution must have the capability to manage and store metadata related to data and quality automation agreements, including details about schema, owners, expectation metrics, data lineage, and data quality metrics. | ||
| 16580 | A.4.29 | The Contractor's proposed solution must have the capability to allow stakeholders to access and query metadata to understand data quality and automation provenance and quality. | ||
| 16581 | A.4.30 | The Contractor's proposed solution must have the capability to provide observability features to monitor the health of data pipelines, detect anomalies, and ensure that data quality and automation agreements are continuously enforced in real-time. | ||
| 16582 | A.4.31 | The Contractor's proposed solution must have the capability to monitor and report on data freshness, accuracy, completeness, and timeliness. | ||
| 16583 | A.4.32 | The Contractor's proposed solution must have the capability to provide comprehensive documentation for each data quality and automation agreement, including schema definitions, business context, expectation metrics, validation rules, and examples of acceptable and unacceptable data. | ||
| 16584 | A.4.33 | The Contractor's proposed solution must have the capability to ensure that documentation is easily accessible to all stakeholders. | ||
| 16585 | A.4.34 | The Contractor's proposed solution must have the capability to align data quality and automation agreements with the organization's data governance framework to ensure consistency in data quality, security, and compliance across all data assets. | ||
| 16586 | A.4.35 | The Contractor's proposed solution must have the capability to maintain logs of all data quality and automation agreement violations, changes, and access to ensure these logs are auditable for compliance and governance purposes. | ||
| 16587 | A.4.36 | The Contractor's proposed solution must have the capability to involve all relevant stakeholders (data producers, consumers, legal, and compliance teams) in the creation and maintenance of data quality and automation agreements. | ||
| 16881 | A.4.37 | The Contractor’s solution must make available in real time all configuration, metadata, and operational data, excluding the data being transferred, in a SQL database, structured in a clear and queryable relational format. While it is acceptable for Binary Large Objects (Blobs) to exist in the database, the information within these Blobs must also be represented in a relational format. This ensures compatibility with reporting tools like Tableau, enabling straightforward analysis and reporting. Details about the data being processed—such as its quality, performance metrics, logging information, alerts, and overall system performance—must be readily accessible through relational queries. | ||
| 16948 | A.4.38 | The Contractor's DQAA Dashboard solution must create and maintain the DQAA dashboard as specified by IDHW. This dashboard is used to manage and report on all aspects of DQAAs. | ||
| 16949 | A.4.39 | The Contractor's DQAA Dashboard solution must have the capability to create a Printer Friendly Version of the ICS for each interface from the DQAA Dashboard. | ||
| 16950 | A.4.40 | The DQAA dashboard will have the capability to import a schema when creating a new DQAA populating all appropriate data elements in the database. The following schema types are supported: Text file: fixed length and delimited, XLM, JSON. | ||
| 16951 | A.4.41 | The DQAA dashboard will have the capability to duplicate an existing DQAA as the startping point for a new one. | ||
| 16952 | A.4.42 | The Contractor's DQAA dashboard solution must have the capability to categorize DQAAs as a Template or Interface upon creation only. | ||
| 16953 | A.4.43 | The Contractor's DQAA dashboard solution must have the capability to version DQAAs enforcing non-overlapping effective dates. | ||
| 16954 | A.4.44 | The Contractor's DQAA dashboard solution must have the capability to maintain all data and query data using filters including, but not limited to subject areas (Medical Claims, Pharmacy Claims, Medicaid Eligibility, Medicare Eligibility, etc.). | ||
| 16957 | A.4.45 | The Contractor's DQAA dashboard solution must include a DQAA Administrator dashboard persona with the ability to monitor data quality, I-MIDAS file processing performance, usage patterns, and error handling, logging, and notifications, creation and management of DQAA’s. | ||
| 16958 | A.4.46 | The Contractor's DQAA dashboard solution must include a DQAA Contributor dashboard persona with the ability to view data quality, I-MIDAS file processing performance, error handling, logging, and notifications, and DQAA’s. | ||
| 16129 | A.4.47 Requirement Removed | The Contractor's solution must provide standard Application Programming Interfaces (APIs) for MMIS Modules to use when integrating with an IDHW designated Electronic Document Management System (EDMS) that include at minimum the ability to add, retrieve, replace, delete, and update an existing document with additional metadata. | ||
| 16130 | A.4.48 Requirement Removed | The Contractor's solution must incorporate the ability to include configurable query parameters in its standard EDMS document search and retrieval APIs. | ||
| 16132 | A.4.49 Requirement Removed | The Contractor's solution must validate that all required metadata is present prior to adding documents to an IDHW designated EDMS. | ||
| 16433 | A.5.1 | The contractor must create Deliverable Expectations Document (DED), and Project Plans identified by the State. All DEDs must include an outline of each deliverable, and representative draft content. The Project Plan(s) will be updated and stored on the IDHW approved repository (currently SharePoint) and be maintained in real time. Deliverable descriptions are located in Appendix F of this RFP. Deliverables include: | ||
| 16408 | A.5.2 | A.5.2 | The Contractor must provide a Business Continuity Plan which adheres to applicable State and federal laws, rules, regulations, and guidelines. The general business continuity capabilities must include, at a minimum, the following: (16408 – DDI and M&O) | |
| A.5.2.1 | Roles and responsibilities | |||
| A.5.2.2 | Checkpoint/restart capabilities | |||
| A.5.2.3 | Retention and storage of back-up files and software | |||
| A.5.2.4 | Solution for continuous Contractor and Agency communications | |||
| A.5.2.5 | Recovery Time Objective (RTO) and Recovery Point Objective (RPO) | |||
| A.5.2.6 | Resumption of all critical operations following a disaster. with all critical operations clearly defined in the Contractor’s State approved Disaster Recovery and Business Continuity Plans | |||
| A.5.2.7 | Back-up procedures, recovery regions, redundancy, and support to prevent and accommodate the disruption of systems and communications | |||
| 16456 | A.5.3 | The Contractor must provide the status of the project to the MMIS Modernization PMO or IDHW designated PMO according to the schedule outlined in the Project Plan in the monthly status reporting for the lifecycle of the project using the IDHW provided template. | ||
| 16436 | A.5.4 | The Contractor must create the SI documentation Deliverables as defined in this scope of work. The Deliverables must be updated and stored on the IDHW approved repository (currently SharePoint) and be maintained in real time. | ||
| 16458 | A.5.5 | The Contractor must provide a Turnover Plan to address the transition approach for all operations, services, on-going work, and module components. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .