S-44300-00017151- MES Attachment H_Initial System Integration Requirements.xlsx
XLSX spreadsheet 107 KB Posted
- Solicitation number
- S-44300-00017151
- Issued by
- Oregon
About this file
System Integration Requirements Document Summary
This file is a comprehensive attachment to the Request for Proposal for Medicaid Enterprise System (MES) System Integration Services issued jointly by the State of Oregon, Oregon Health Authority (OHA), and Oregon Department of Human Services (ODHS). The document establishes a detailed classification structure and functional requirements for system integration services across multiple operational domains. The MES initiative encompasses three phases: Phase 1 involves planning and preparation, Phase 2 covers application development, implementation, and legacy systems integration, and Phase 3 addresses ongoing maintenance and future integrations. The Solution must support the management of member relationships, eligibility data exchange, workflow automation, reporting and analytics, API management, data integrity, performance monitoring, and security compliance across the State's healthcare programs. Key requirements include support for near-real-time and real-time data exchange, master data management with entity matching and deduplication capabilities, extraction-transformation-load (ETL) and extraction-load-transformation (ELT) processing patterns, and comprehensive integration with State-identified external systems and healthcare registries.
The requirements document encompasses ten major functional categories totaling over 300 specific requirements across security and compliance, system and data integrity, application performance and scalability, integration and interoperability, software development and deployment, user experience and accessibility, business and functional requirements, IT governance and supportability, standards and compliance, and contractor support obligations. Critical security mandates include HIPAA compliance, SOC 2 Type II attestation, FedRAMP authorization or equivalent security posture, multi-factor authentication, role-based access controls, encryption at rest and in transit, centralized logging and audit trails, and zero-trust security architecture. The Solution must support State-approved data standards including HL7, FHIR, EDI X12, XML, and JSON formats, maintain comprehensive data lineage and reconciliation controls, provide operational dashboards and self-service business intelligence capabilities, and enable authorized State users to maintain and access documentation and metadata without contractor intervention. All artifacts, including interface control documents, certification materials, test evidence, and system documentation, must be maintained in State-designated repositories with version control, change traceability, and direct State access throughout the contract term.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| S-44300-00017151- MES Attachment Ia_TRA Framework.docx | DOCX document | |
| S-44300-00017151- MES Attachment A_System Integration Platform.docx | DOCX document | |
| S-44300-00017151- MES Attachment_J_Statewide_Information_and_Cyber_Security_Standards.xlsx | XLSX spreadsheet | |
| RFP S-44300-00017151.pdf | ||
| S-44300-00017151- MES Attachment Ib_TRA Standards.xlsx | XLSX spreadsheet | |
| S-44300-00017151- MES Attachment F COBID Certification - Outreach Plan.docx | DOCX document | |
| S-44300-00017151- MES Attachment D Reference Check Form.docx | DOCX document | |
| S-44300-00017151- MES Attachment_K_MMIS Interface List.xlsx | XLSX spreadsheet | |
| S-44300-00017151- MES Attachment E_Price Proposal Form.xlsx | XLSX spreadsheet | |
| S-44300-00017151- MES Attachment C Proposer Information and Certification Sheet.docx | DOCX document | |
| S-44300-00017151- MES Attachment G Responsibility Inquiry.docx | DOCX document | |
| S-44300-00017151- MES Attachment B Disclosure Exemption Affidavit.docx | DOCX document |
Show all 12
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
Classification Structure
| S-44300-00017151- Medicaid Enterprise System (MES) System Integration Services | AttH | |
| Code | Name | Description |
| SAC | Security and Compliance | |
| SAC.iam | Identity & Access Management | Authentication, role-based access control (RBAC), multi-factor authentication (MFA). |
| SAC.siem | Security Information & Event Management | Logging, monitoring, alerting, forensic analysis. |
| SAC.tdr | Threat Detection & Response | Intrusion detection, vulnerability scanning, malware protection. |
| SAC.edd | Encryption & Data Protection | Data at rest/in-transit encryption, key management, secure storage. |
| SAC.sh | Security Hygiene | set of practices and actions that help maintain the safety and integrity of systems, data, and networks. |
| SDI | System & Data Integrity | |
| SDI.aal | Audit & Logging | Comprehensive record of transactions, changes, and access. |
| SDI.dvi | Data Validation & Integrity | Ensuring data consistency, error handling, deduplication |
| SDI.bccr | Business Continuity & Disaster Recovery | Business continuity, data redundancy, recovery objectives |
| APS | Application Performance & Scalability | |
| APS.pmo | Performance Monitoring & Optimization | Load balancing, response time tracking, auto-scaling. |
| APS.rm | Resource Management | CPU, memory, database optimization, cloud cost management. |
| IAI | Integration & Interoperability | |
| IAI.am | API Management | RESTful APIs, GraphQL, API gateways, rate limiting. |
| IAI.dei | Data Exchange & Interoperability | HL7, FHIR (for healthcare), EDI, JSON, XML. |
| IAI.si | System Integration | Connecting with third-party services, middleware, enterprise service buses (ESB). |
| SDD | Software Development & Deployment | |
| SDD.sa | Software Architecture | Monolith vs. microservices, event-driven architecture |
| SDD.tqa | Testing & Quality Assurance | Unit testing, integration testing, security testing, test automation. |
| UEA | User Experience & Accessibility | |
| UEA.uix | User Interface (UI) & User Experience | Frontend design principles, usability testing. |
| UEA.acc | Accessibility | WCAG standards, assistive technology support. |
| BFR | Business & Functional Requirements | |
| BFR.cbl | Core Business Logic | The essential functionality the software provides. |
| BFR.waa | Workflow & Automation | Business process automation, task scheduling. |
| BFR.raa | Reporting & Analytics | Dashboards, visualization tools, business intelligence (BI). |
| ITGS | IT Governance & Supportability | |
| ITGS.itsm | IT Service Management (ITSM) | Incident management, service requests, ITIL framework adherence. |
| ITGS.cmv | Change Management & Versioning | Release notes, rollback plans, feature toggles. |
| ITGS.dat | Documentation & Training | User manuals, developer guides, onboarding materials. |
| SC | Standards & Compliance | |
| SC.inst | Industry Standards | Support for open standards (e.g., NIEM, NIST, HL7, FHIR) |
| SC.crf | Compliance with Regulatory Frameworks | HIPAA, SOC2, etc. |
| SC.is | Interoperability Standards | Data sharing, messaging protocols (e.g., EDI X12, XML, JSON). |
| NFR | Contractor Support Requirement | |
| NFR.pp | Project Planning | Planning activities including things like working with other Contractors to come up with mitigation plans, etc. |
| NFR.vo | Contractor Obligations | Commitments from the Contractor that are not specific to the application. Things like proving outcomes. |
| NFR.pm | Project Management | Contractor project management responsibilities |
| NFR.pers | Personnel | Contractor personnel requirements |
Acronym List
| Acronym | Meaning | Additional Notes |
| ACA | Affordable Care Act | |
| AD | Active Directory | |
| ADA | Americans with Disabilities Act | |
| API | Application Programming Interface | |
| BCDR | Business Continuity and Disaster Recovery | |
| BPMN | Business Process Management Notation | |
| CMS | Center for Medicare and Medicaid Services | |
| CR | Certification Review | |
| DDI | Design, Development, Implementation | |
| DED | Deliverable Expectation Document | |
| DMZ | Demilitarized Zone | |
| DRS | Designated Record Set | |
| EDI | Electronic Data Interchange | |
| EDW | Enterprise Data Warehouse | |
| EIN | Employer Identification Number | |
| ERD | Entity Relational Diagrams | |
| ESB | Enterprise Service Bus | |
| ETL | Extract, Transform, and Load | |
| ELT | Extract, Load, and Transform | |
| FedRAMP | Federal Risk and Authorization Management Program | |
| FHIR | Fast Healthcare Interoperability Resources | |
| FIPS | Federal Information Processing Standard | |
| HIPAA | Health Insurance Portability and Accountability Act | |
| HITECH | Health Information Technology for Economic and Clinical Health Act | |
| HL7 | Health Level 7 | |
| ICAP | Integrated Customer Access Portal | |
| ICD | Interface Control Document | |
| IMS | Integrated Master Schedule | |
| IV&V | Independent Verification and Validation | |
| KPI | Key Performance Indicators | |
| MES | Medicaid Enterprise | |
| MFA/2FA | Multi-factor Authentication/Two-Factor Authentication | |
| MITA | Medicaid Information Technology Architecture | |
| MMIS | Medicaid Management Information System | |
| NIEM | National Information Exchange Model | |
| NIST | National Institute of Standards and Technology | |
| NPI | National Provider Identifier | |
| NSA | National Security Agency | |
| ODS | Operational Data Store | |
| ORR | Operational Readiness Review | |
| PHI | Personal Health Information | |
| PII | Personally Identifiable Information | |
| PMI | Project Management Institute | |
| PMO | Project Management Organization | |
| QA/QC | Quality Assurance/Quality Control | |
| RCA | Root Cause Analysis | |
| RDBMS | Relational Database Management System | |
| RFP | Request for Proposal | |
| SI | Systems Integrator | |
| SLA | Service Level Agreement | |
| SMC | Streamlined Modular Certification | |
| SOA | Service-Oriented Architecture | |
| SOC | Service Organization Controls | |
| SQL | Structure Query Language | |
| SSAE-16 | Statement on Standards for Attestation Engagements | |
| SSN | Social Security Number | |
| SSNRI | Social Security Number Removal Initiative | |
| SSO | Single Sign-on | |
| SURS | Substance Use and Recovery Services | |
| TIN | Tax Identification Number | |
| TPL | Third Party Liability | |
| UI | User Interface | |
| UAT | User Acceptance Testing | |
| X12 | Electronic Data Interchange Standard X12 |
Terms
| Term | Description |
| Solution | The totality of packaged software and services offering supplied by the Contractor, designed to connect disparate systems, applications, or data sources—enabling end-to-end interoperability, automated workflows, and unified data exchange across an enterprise ecosystem. |
| Phase 1 | Phase 1 is the planning and preparating phase that will culiminate with the Phase 2/3 plan |
| Phase 2 | Application development,implementation and legacy interfaces integration |
| Phase 3 | Ongoing maintenance and future integrations. |
| Service (Category) | This field indicates if its an activity to be performed (e.g. ensure compatability) vs a function of the system itself (e.g. WCAG compliant) |
Functional Requirements
| Requirement Section | Service | Subsection | Phase | ReqID | Req. Language | Column1 |
| Application Performance & Scalability | Y | Performance Monitoring & Optimization | 2 | APS.pmo.01 | The Contractor shall continuously monitor the operation of the Solution to detect and prevent immediate or ongoing adverse impacts to the State’s programs and services, including identification and correlation of abnormal conditions, performance degradation, and failures affecting availability, performance, integrations, and business-process execution. | |
| Application Performance & Scalability | Y | Performance Monitoring & Optimization | 2 | APS.pmo.01 | The Contractor shall implement automated remediation mechanisms for defined degradation and failure scenarios, consistent with mutually approved standards and operating procedures. Automated remediation capabilities shall be configurable, documented, and testable in the State’s environments. | |
| Application Performance & Scalability | Y | Performance Monitoring & Optimization | 2 | APS.pmo.01 | The Contractor shall provide tools, dashboards, and reports for comprehensive performance monitoring, trending, and reporting across the Solution, including transaction tracing from point of service initiation through completion of the business process at the end points defined in mutually approved standards. Tools shall support configurable thresholds, alert routing rules, correlation across modules, and exportable reporting. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.02 | The Solution shall include the ability to support automated batch processing with logging of all events (e.g., timestamps, record counts, errors) and reporting of processing status. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.03 | The Solution shall facilitate real-time data processing, including exception handling, validation, reconciliation, and synchronization across modules. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.04 | The Solution shall include an API operations dashboard that provides the State with view-only access to service and API operational status, including real-time availability indicators for services and APIs. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.04 | The Solution shall support the capability to receive, ingest, and display messages and alerts from external systems in real time within the API operations dashboard. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.04 | The Solution shall automatically monitor system availability by periodically verifying that each module integration point is operating as expected. The State shall define the verification frequency for each module integration point. Verification results shall be made available to the State via dashboards and/or exportable reports. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.04 | Where technically feasible and mutually approved, the Solution shall support automated recovery actions (e.g., service restart or failover) for defined integration-point and service failures. Automated recovery actions and scenarios shall be documented and testable in the State’s environments. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.05 | The Solution shall allow administrators to simulate high-load scenarios to identify potential failure points and shall support caching mechanisms to reduce redundant database queries and improve response times. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.06 | The Solution shall detect, log, and report database queries that exceed State-defined, configurable performance thresholds, enabling identification and remediation of performance degradation. Performance thresholds shall be configurable by the State and may vary by environment, workload, or data domain. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.07 | The Solution shall be capable of processing the Medicaid business transaction volumes and processing loads defined in State-provided workload assumptions and processing standards and shall maintain efficient handling of large transaction volumes through scalable architecture and configuration. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.07 | The Contractor shall define, implement, and maintain measurable performance metrics for State-identified business transactions and critical batch and reporting processes, including throughput and latency measures, subject to State approval. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.07 | The Contractor shall execute performance and load testing against State-provided workload assumptions and approved performance metrics and shall provide test plans, test cases, execution results, and findings demonstrating whether performance criteria were met. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 2 | APS.pmo.07 | The Solution shall provide monitoring and trend reporting for approved performance metrics over time to identify performance degradation, including baseline establishment, periodic measurement, thresholding, and reporting sufficient to support operational tuning and remediation. | |
| Application Performance & Scalability | N | Performance Monitoring & Optimization | 3 | APS.pmo.08 | The Solution shall distinguish between transactional, streaming, and batch workloads when scaling. | |
| Application Performance & Scalability | N | Resource Management | 2 | APS.rm.01 | The Solution shall automatically allocate and deallocate resources (e.g., CPU, memory, storage, and bandwidth) based on workload demands and predefined thresholds. | |
| Application Performance & Scalability | N | Resource Management | 2 | APS.rm.02 | The Solution shall support resource pooling to enable shared use of resources across multiple applications or services to optimize utilization. | |
| Application Performance & Scalability | N | Resource Management | 2 | APS.rm.03 | The Solution shall provide predictive analytics to forecast resource utilization and associated costs based on usage trends. | |
| Application Performance & Scalability | N | Resource Management | 2 | APS.rm.04 | The Solution shall identify underutilized resources and support actions to reduce waste, including scaling down or shutting down idle services where appropriate. | |
| Application Performance & Scalability | N | Resource Management | 2 | APS.rm.05 | The Solution shall forecast future resource needs based on historical data, growth trends, and upcoming projects to ensure adequate capacity. | |
| Application Performance & Scalability | N | Resource Management | 2 | APS.rm.06 | The Solution shall automatically detect resource bottlenecks (e.g., overutilization or underutilization) and support corrective actions such as resource reallocation or failover. | |
| Business and Functional Requirements | N | Core Business Logic | 2 | BFR.cbl.01 | The Solution shall support management of member and related-party relationships required to administer the State’s healthcare programs, including relationships originating from integrated source systems, in accordance with State-defined relationship definitions and governance. | |
| Business and Functional Requirements | N | Core Business Logic | 2 | BFR.cbl.02 | The Solution shall link all services to a single member regardless of the number of historical changes in member identifier. | |
| Business and Functional Requirements | N | Core Business Logic | 2 | BFR.cbl.03 | The System Integration Platform shall support search and retrieval of data that is managed, processed, staged, or persisted within the System Integration Platform, including data received from integrated source systems that is stored within the platform in accordance with State-approved integration and retention standards. | |
| Business and Functional Requirements | N | Core Business Logic | 2 | BFR.cbl.03 | The search and retrieval capability shall not require or perform direct querying of external system databases. Search shall be limited to data stored, indexed, or otherwise made available within the System Integration Platform through State-approved interfaces. | |
| Business and Functional Requirements | N | Core Business Logic | 2 | BFR.cbl.03 | The search and retrieval capability shall provide sufficient metadata to locate and interpret results (e.g., source system, interface identifier, date/time, correlation identifier, and status, as applicable) and shall enforce access controls and audit logging consistent with State security requirements. | |
| Business and Functional Requirements | Y | Core Business Logic | 2 | BFR.cbl.04 | The Solution shall enforce State-defined business rules applicable to in-scope processes and transactions, consistent with State security and access control policies. | |
| Business and Functional Requirements | Y | Core Business Logic | 2 | BFR.cbl.04 | The Contractor shall implement and enforce only business rules that are defined and approved by the State and shall support State governance for rule definition, review, approval, and change control, including role-based permissions and auditability of rule changes. | |
| Business and Functional Requirements | Y | Core Business Logic | 2 | BFR.cbl.04 | The Solution shall allow authorized users to configure and maintain State-defined business rules through configuration, where feasible and State-approved, without requiring custom code changes for routine rule updates. | |
| Business and Functional Requirements | Y | Core Business Logic | 2 | BFR.cbl.04 | The Contractor shall support State-defined classification of business rules (e.g., core/critical versus secondary/supporting) and shall maintain traceability of each rule to affected processes, transactions, or interface flows, including version history and effective dates. | |
| Business and Functional Requirements | Y | Core Business Logic | 2 | BFR.cbl.04 | The Contractor shall provide test cases and execution evidence demonstrating correct enforcement of State-approved business rules, including representative coverage of core and critical rules and associated security and access control constraints. | |
| Business and Functional Requirements | N | Core Business Logic | 2 | BFR.cbl.05 | The Solution shall support flexible configuration of business rules to allow adjustments as business requirements change without requiring code changes. | |
| Business and Functional Requirements | N | Core Business Logic | 2 | BFR.cbl.06 | The Solution shall ensure that business transactions are processed atomically such that business logic is executed completely or no change occurs in the event of an error. | |
| Business and Functional Requirements | N | Core Business Logic | 2 | BFR.cbl.07 | The Solution shall handle concurrent business transactions in a manner that preserves data integrity and prevents race conditions or inconsistent outcomes. | |
| Business and Functional Requirements | N | Core Business Logic | 2 | BFR.cbl.08 | The Solution shall provide a unified portal that serves as the landing page for all Solution modules and applications. | |
| Business and Functional Requirements | N | Core Business Logic | 2 | BFR.cbl.09 | The Solution shall support decoupling and seamless absorption of functions from existing legacy systems without deviation from State-defined business rules. | |
| Business and Functional Requirements | N | Core Business Logic | 2 | BFR.cbl.11 | The Solution shall integrate with or expose a centralized business rules repository to enable reuse of approved business rules across modules. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.01 | The System Integration Platform shall provide an Operational Data Store that supports persistence of integration data and enables downstream data consumption through standards-based interfaces, including integration with a future Enterprise Data Warehouse. | |
| Business and Functional Requirements | Y | Reporting & Analytics | 2 | BFR.raa.02 | The Solution shall provide transparency for all data fields and calculated values presented in reports, including the ability for the State to identify data sources, transformation logic, and calculation methods used to produce reported values. | |
| Business and Functional Requirements | Y | Reporting & Analytics | 2 | BFR.raa.02 | For each report delivered or modified, the Contractor shall provide report design documentation sufficient for State verification and reuse, including data element inventories, source-to-report mappings, calculation logic and formulas for derived fields, and analytic protocols and assumptions. | |
| Business and Functional Requirements | Y | Reporting & Analytics | 2 | BFR.raa.02 | For each report delivered or modified, the Contractor shall provide implementation logic used to generate report outputs, which may include State-approved SQL queries, pseudo code, and/or narrative logic descriptions sufficient to reproduce and validate results. | |
| Business and Functional Requirements | Y | Reporting & Analytics | 2 | BFR.raa.02 | The Contractor shall maintain version history and change documentation for report logic, including description of changes, rationale, and effective dates, sufficient to support auditability and troubleshooting. | |
| Business and Functional Requirements | N | Reporting & Analytics | 3 | BFR.raa.03 | The Solution shall provide a suite of State-defined online reports that enable users to generate customized operational reports using predefined parameters (e.g., provider number, procedure code, date of service). | |
| Business and Functional Requirements | Y | Reporting & Analytics | 2 | BFR.raa.04 | The Solution shall collect, process, store, and maintain data necessary to support CMS reporting requirements, including T-MSIS, CMS-64, MMA-Part D, and Buy-in, and shall serve as an integration and staging capability rather than a replacement enterprise data warehouse. | |
| Business and Functional Requirements | Y | Reporting & Analytics | 2 | BFR.raa.04 | Data stored in the Solution for CMS reporting support shall be limited to staging, transformation, and reporting enablement needs as defined by the State and shall not establish the Solution as the system of record unless explicitly designated by the State. | |
| Business and Functional Requirements | Y | Reporting & Analytics | 2 | BFR.raa.04 | The Contractor shall document and maintain source-of-truth designation and end-to-end data lineage for CMS reporting datasets supported by the Solution, sufficient to support auditability and reconciliation. | |
| Business and Functional Requirements | Y | Reporting & Analytics | 2 | BFR.raa.04 | Where data is duplicated from source systems for staging or reporting enablement, the Contractor shall implement State-approved reconciliation controls to validate completeness and accuracy. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.05 | The Solution shall provide a method to access, query, and report against archived data external to the Operational Data Store. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.06 | The Solution shall have the capability to respond to a request to provide a report containing the Designated Record Set for a given entity. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.07 | The Solution shall capture, maintain, and transmit the data items required for State or Federal reporting to the State’s enterprise data warehouse. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.08 | The Solution shall provide a dashboard presenting a current inventory of systems utilizing the System Integration Solution. | |
| Business and Functional Requirements | Y | Reporting & Analytics | 3 | BFR.raa.09 | The Solution shall make narrative descriptions and definitions of data elements, codes, and abbreviations available to authorized State users to support reporting and interpretation. | |
| Business and Functional Requirements | Y | Reporting & Analytics | 3 | BFR.raa.09 | Narrative descriptions and definitions shall be available through State-approved, system-accessible metadata or documentation mechanisms and shall not be limited to a single presentation method. | |
| Business and Functional Requirements | Y | Reporting & Analytics | 3 | BFR.raa.09 | Authorized State users shall be able to access, search, and retrieve metadata and definitions directly without contractor intervention, consistent with State-approved access controls. | |
| Business and Functional Requirements | Y | Reporting & Analytics | 3 | BFR.raa.09 | The Contractor shall maintain metadata and documentation in a current state consistent with State-approved governance and change control processes. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.10 | The Solution shall support initiation of reports through on-demand, scheduled (including non-business hours), and event-driven methods with distribution of results to specified secure locations. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.11 | The Solution shall allow authorized users to view, sort, export, and print dashboard and report data in multiple formats (e.g., HTML, Excel, TXT, CSV, PDF, or delimited). | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.12 | The Solution shall provide self-service business intelligence tools for ad-hoc reporting and analysis by end users. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.13 | The Solution shall support advanced analytics capabilities to derive predictive or actionable insights for State-approved use cases, subject to State-approved governance, security, and data classification constraints. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.13 | Any AI/ML processing shall comply with State security policies and data classification rules and shall be configurable to restrict access to prohibited data classifications. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.13 | The Contractor shall implement an approval and documentation process for AI/ML use cases and datasets sufficient to support traceability and auditability. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.13 | The Solution shall provide logging and auditability for AI/ML activities, including data access, model execution, and output generation. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.15 | The Solution shall leverage AI/ML models to analyze trends in subject areas such as Medicaid claims, provider behavior, and fraud detection, subject to State-approved constraints. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.16 | The Solution shall provide dashboards for monitoring SLA compliance, failed transaction counts, and retry rates in near real time. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.17 | The Solution shall provide dashboards highlighting data quality issues across modules (e.g., missing, duplicate, or stale data). | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.18 | The Solution shall provide documentation and explainability for AI/ML models used in analytics, reporting, or fraud detection, including clear descriptions of how outputs are generated. | |
| Business and Functional Requirements | N | Reporting & Analytics | 2 | BFR.raa.19 | The Solution shall ensure that AI/ML models used in reporting or decision support are tested for bias and that documented corrective actions are implemented to prevent discriminatory outcomes. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.01 | The Solution shall provide a secure, configurable workflow and request-management capability to support State-approved operational processes, including role-based access controls and audit logging consistent with State security requirements. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.01 | The Solution shall include a web-based portal for authorized users to submit, view, monitor, and manage service requests from multiple endpoints, including request status visibility and user notifications consistent with State-approved processes. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.01 | The Solution shall support configurable linear and dynamic workflows, including conditional logic and business rules that control task initiation, routing, and completion. Workflow configuration shall be maintainable without custom code where feasible and State-approved. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.01 | The Solution shall include scheduling and automation features to support recurring or triggered workflow activities and shall provide reporting and dashboard capabilities sufficient for operational monitoring and auditability. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.01 | The Solution shall support management and tracking of State-approved data migration activities, including initiation, execution tracking, approvals as applicable, and status reporting. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.01 | The Solution shall support management and tracking of State-approved data synchronization activities, including initiation, execution tracking, exception handling as applicable, and status reporting. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.02 | The Solution shall allow authorized users to define and configure workflows through a graphical interface and/or configuration files without requiring custom code. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.03 | The Solution shall enable users to create and view process maps using flow diagrams or Business Process Model and Notation (BPMN) to represent business workflows. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.04 | The Solution shall support workflows with conditional logic, including branching and looping, based on State-defined business rules. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.05 | The Solution shall maintain version control for workflows, allowing authorized users to track, roll back, or restore previous workflow configurations. | |
| Business and Functional Requirements | N | Workflow & Automation | 3 | BFR.waa.06 | The Solution shall provide predefined templates for common workflows to reduce the time required to create new processes. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.07 | The Solution shall support workflow steps requiring approval by defined roles before proceeding to subsequent steps. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.08 | The Solution shall automatically trigger predefined tasks based on State-approved business rules or event conditions. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.09 | The Solution shall support scheduling of tasks to run at specified times, intervals, or event-based triggers. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.10 | The Solution shall support task prioritization to ensure higher-priority tasks are executed before lower-priority tasks. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.11 | The Solution shall provide workflow analytics enabling authorized users to identify bottlenecks, inefficiencies, and common failure points using performance indicators such as cycle time, wait time, and exception frequency. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.11 | The Solution shall provide reporting and trend analysis for workflow performance over time, including dashboards and metrics for monitoring throughput, execution duration, and exception rates. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.11 | The Solution shall support performance tuning and optimization of workflows by enabling authorized users to revise workflow configuration to improve outcomes, consistent with State-approved business rules and controls. | |
| Business and Functional Requirements | N | Workflow & Automation | 2 | BFR.waa.11 | The Solution shall support controlled workflow changes, including role-based permissions for modification and retention of version history and audit logs sufficient to support governance and traceability. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.01 | The Solution shall support secure modern and approved legacy communication protocols as required by the State, while maintaining backward compatibility with State-approved legacy systems. | |
| Integration & Interoperability Requirements | Y | API Management | 2 | IAI.am.02 | The Contractor shall collaborate with the State to design, configure, and maintain the technical integrations and APIs required to support the State’s healthcare programs. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.03 | The Solution shall make system interfaces (including APIs and service endpoints) available to the integration platform to support bidirectional message exchange and reliable system-to-system communication. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.04 | The Solution shall provide APIs that support configuration rather than custom development to enable rapid deployment and integration of legacy and new applications. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.05 | The Solution shall utilize a service registry to manage services operating through the Solution, including storage of machine-readable service metadata such as endpoint location, routing information, and load-balancing attributes. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.06 | The Solution shall allow authorized system administrators to create, update, and manage entries within the service registry. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.07 | All public interfaces shall be documented using the prevailing documentation standard appropriate to the interface type and consistent with State-approved integration standards. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.07 | For each public interface, the Contractor shall provide documentation sufficient for implementation and operations, including interface purpose, endpoints or locations, data formats or schemas, required fields, security requirements, error handling, versioning, and operational considerations applicable to the interface type. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.07 | Documentation shall support multiple interface types using the standard documentation approach appropriate to each type, which may include REST APIs, SOAP services, file-based transfers, messaging or event interfaces, and batch exchanges. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.08 | The Solution’s API gateway shall be scalable, highly available, and capable of supporting State-defined uptime and performance expectations. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.09 | The Solution shall support API versioning, deprecation, and retirement while maintaining backward compatibility in accordance with State-approved standards. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.10 | The Solution shall support API rate limiting, throttling, and quota enforcement to protect services from misuse or abuse. | |
| Integration & Interoperability Requirements | N | API Management | 2 | IAI.am.11 | The Solution shall support asynchronous communication, alerting, and notification capabilities. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.01 | The Solution shall support near–real-time data exchange through APIs, where appropriate, when interfacing with State data. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.02 | The Solution shall support exchange of clinical and non-clinical data using State-defined data standards and formats, including structured and unstructured data, as required for integrated systems. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.03 | The Contractor shall standardize the structure, documentation, and visibility of data exchanges and integration interfaces to support automated electronic data exchange and promote interoperability across the State’s enterprise. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.03 | The Contractor shall define, document, and implement interoperability and security standards for electronic data exchanges, subject to State review and approval, including authentication, authorization, encryption, logging, auditability, and data validation. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.03 | Where real-time exchange is feasible and State-approved, the Contractor shall provide and publish standards-based FHIR implementations for real-time system-to-system communication. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.03 | Where real-time exchange is not feasible due to validated and State-approved constraints, the Contractor shall provide a standard API-based interface consistent with State-approved interoperability and security standards. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.03 | Where API-based exchange is not feasible due to validated and State-approved constraints, the Contractor shall provide a defined exchange format and State-approved publishing location to collect, validate, transform, and load data between systems. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.03 | For each integration, the Contractor shall document the selected exchange tier, justification for deviations from higher tiers, and applicable constraints, and obtain State approval prior to implementation. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.04 | The Contractor shall reconcile SI ODS data elements with the data elements used by each in-scope module component required for data interchange. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.04 | For each required interchange, the Contractor shall produce and maintain State-approved data mapping and interchange specifications sufficient to implement and test data receipt and transmittal. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.04 | The Contractor shall manage reconciliation outcomes and mapping artifacts through State-approved governance, including version control and change traceability. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.05 | The Contractor shall develop and maintain Application Programming Interfaces (APIs) between the SI Operational Data Store (ODS) and State-identified non-Medicaid Agency enterprise systems to enable approved transactional data sharing. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.05 | The APIs and associated integration flows shall support the transformation and exchange of converted data as defined by State-approved conversion and data-mapping specifications. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.05 | All APIs shall be designed and implemented in accordance with State-approved interoperability, integration, and security standards, including authentication and authorization, encryption in transit, logging and auditability, error handling, and versioning. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.05 | The Contractor shall maintain an inventory and documentation for each API sufficient to support implementation and operations, including endpoint definitions, data schemas, mappings and transformations, validation rules, error handling, and operational considerations, stored in the State-designated repository with direct State access. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.05 | The Contractor shall submit API and interface specifications for State review and approval prior to implementation and shall implement API changes through State-approved change control. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.06 | The Contractor shall implement State-directed integrations between in-scope MES components and State-identified external systems using State-approved standards and governance. | |
| Integration & Interoperability Requirements | Y | Data Exchange & Interoperability | 2 | IAI.dei.06 | For each integration, the Contractor shall produce and maintain State-approved interface specifications, data mappings, security controls, test evidence, and operational runbooks. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.07 | The Solution shall support data exchange via web services, EDI X12, message queues, or other State-approved message brokering protocols. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.08 | The Solution shall send and receive real-time discrete transactions between modules and the State’s integration platform to reduce reliance on bulk data transfers. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.09 | The Solution shall support exchange of documents, images, metadata, and other unstructured data with external systems and State enterprise healthcare systems. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.10 | The Solution shall support secure data sharing and federation with authorized data sharing partners. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.11 | The Solution shall support interoperability using State-approved messaging and data exchange formats appropriate to the interface type and use case. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.11 | The Solution shall support XML and JSON messaging formats where appropriate. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.11 | The Solution shall support additional industry-standard and State-approved formats as required and documented in interface specifications. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.11 | For each interface, the Contractor shall document message formats, schemas, validation rules, and versioning using State-approved documentation standards. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.12 | The Solution shall support message orchestration capabilities, including content-based and header-based routing. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.13 | The Solution shall support protocol bridging to enable secure communication across multiple transport protocols. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.14 | The Solution shall support message enrichment and transformation capabilities for format conversion and data augmentation. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.15 | The Solution shall support reliable message delivery semantics for asynchronous integrations, including configurable “at least once” delivery and State-approved “exactly once” processing where feasible. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.15 | The Solution shall support persistent message queuing to prevent message loss during failures or restarts. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.15 | The Solution shall provide dead letter queue capabilities with visibility, triage, and controlled reprocessing by authorized users. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.15 | The Solution shall support configurable retry mechanisms, including retry limits and backoff strategies. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.15 | The Solution shall provide operational visibility into message processing, including queue depth, latency, retries, failures, and alerting. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.17 | The Solution shall natively support event streaming platforms for real-time data sharing. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.18 | The Solution shall provide or support a canonical or standardized data model to enable enterprise-wide interoperability. | |
| Integration & Interoperability Requirements | N | Data Exchange & Interoperability | 2 | IAI.dei.19 | The Solution shall support backward-compatible schema changes without breaking existing consumers. | |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.dei.20 | The Solution shall provide real-time access to transactional data for all module interface components. | Req |
1: The Solution shall receive, process, and transmit member eligibility information exchanged with State-identified external sources (including the State’s Eligibility Systems) using State-approved interface patterns and security standards.
2: The Solution shall support both real-time and near real-time eligibility exchange patterns as designated by the State for each eligibility interface flow.
3: The Solution shall produce processing results sufficient to support error correction and synchronization for eligibility exchanges, including both summary (“total”) and detailed information by interface flow (e.g., counts received/processed/succeeded/failed, and detailed failure records with error reasons and correlation identifiers), accessible to authorized State users.
4: The Solution shall support the application and transmission of State-approved reconciliation changes for eligibility exchanges, including the ability to process corrections, reprocess affected transactions as applicable, and maintain auditability of reconciliation actions.
5: The Solution shall maintain traceability for eligibility exchanges, including correlation identifiers, timestamps, source and destination identifiers, and audit logs for processing, retransmission, and reconciliation actions sufficient to support investigation and compliance.
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.02 | The Solution shall support State-approved designation of authoritative data sources by data domain and shall enforce use of those designations in SI-managed integration and staging flows as applicable. |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.02 | The Contractor shall document and maintain end-to-end data lineage from authoritative sources through SI processing to downstream consumption points, including transformations and mappings, sufficient to support auditability and reconciliation. |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.02 | The Solution shall support State-approved interfaces to authoritative data sources needed for SI scope, including documentation, security controls, and change control consistent with State standards. |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.03 | The Solution shall support Extract, Transform, and Load (ETL) and Extract, Load, and Transform (ELT) processing patterns as appropriate to State-approved use cases and architectures. |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.03 | ETL/ELT processes shall implement State-approved data mappings, transformation rules, and validation controls, including error handling and exception reporting sufficient to support remediation and reprocessing. |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.03 | The Solution shall support scheduling, orchestration, and operational monitoring for ETL/ELT processes, including run status, throughput, failures, retries, and audit logs with correlation identifiers sufficient for troubleshooting and compliance. |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.03 | The Contractor shall document ETL/ELT workflows in the State-designated repository and maintain version control and change traceability. |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.04 | The Solution shall include tooling sufficient to design, execute, schedule, monitor, and audit ETL/ELT workflows required for State-approved data management and data sharing use cases, including error handling and operational reporting. |
| Integration & Interoperability Requirements | N | System Integration | 2 | IAI.si.05 | The Solution shall provide the ability to automatically transform data as it passes between source and destination systems in support of State-approved data interchange requirements. |
| Integration & Interoperability Requirements | N | System Integration | 2 | IAI.si.05 | Data transformations shall be executed in accordance with State-approved mapping specifications and transformation rules, including code/value translations, normalization, and derived-field calculations where applicable. |
| Integration & Interoperability Requirements | N | System Integration | 2 | IAI.si.05 | The Solution shall validate transformed data against State-approved schemas and business rules as applicable and shall provide error handling for transformation failures, including logging and exception routing sufficient to support remediation and reprocessing. |
| Integration & Interoperability Requirements | N | System Integration | 2 | IAI.si.05 | The Contractor shall document transformation logic, source-to-target mappings, rules, and versioning in the State-designated repository and maintain traceability of changes through State-approved change control. |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.06 | The Solution shall support configuration and execution of scheduled events (e.g., reports, file transfers, processes, notifications) in addition to real-time and event-driven processing. |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.07 | The Contractor shall develop and maintain ERDs and associated integration/object models sufficient to represent SI ODS data structures, integration data structures, and key exchanged data structures for in-scope interfaces, consistent with State-approved standards. |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.07 | The Contractor shall maintain alignment between logical, physical, and object/integration models by updating artifacts to reflect State-approved changes to data structures, interfaces, and implemented designs. |
| Integration & Interoperability Requirements | Y | System Integration | 2 | IAI.si.07 | The Contractor shall store modeling artifacts in the State-approved repository with direct State access consistent with access controls. |
| Integration & Interoperability Requirements | N | System Integration | 2 | IAI.si.08 | The Solution shall receive, process, and transmit member eligibility information exchanged with State-identified external sources using State-approved interface patterns and security standards. |
| Integration & Interoperability Requirements | N | System Integration | 2 | IAI.si.08 | The Solution shall support both real-time and near real-time eligibility exchange patterns as designated by the State for each eligibility interface flow. |
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 .