Part 4 - Iowa Medicaid Enterprise

RFP MED-12-001 | Technical ProposalIowa Medicaid Enterprise System Service Procurement | MMIS and Core MMIS Operationserror cases, business rules tied to the use case, and the error conditions. The extracted business rules willbe referenced and linked to the use cases so that development team can implement them in the appropriatedevelopment cycle.During configuration and development, links will be maintained between implemented rules and the BREdocument. RuleIT contains a documentation tab, which is used to reference the rule extracted out of theBRE process. Reconciliation status reports will be published detailing the traceability between the rulesdocumented in the BRE, requirement document, design document and the test cases.8.3.1.2.4 Incorporating Existing Rules Into the Rules EngineRFP Section 6.3.1.2, Requirement hUsing the process described in Section 8.3.1.2.3, Team Noridian will present rules traceability to theDepartment as a part of JAD sessions. The Department will have an opportunity to review which rules areincorporated into the rules engine initial via the JAD sessions and secondarily during the review andapproval of the DSD for each business area.8.3.1.2.5 Identify and Develop RulesRFP Section 6.3.1.2, Requirement i and jAll rules are requirements driven with our iVision360 ISDM. Additional rules will be identified as a partof the requirements validation and design process and incorporated into the configuration anddevelopment work streams through the DSD approval process. The timeframes for incorporating ruleswill be defined as a part of the Project Work Plan review and approval process.8.3.1.2.6 Benefit Plan Approval from the DepartmentRFP Section 6.3.1.2, Requirement kTeam Noridian presents formats for rules documentation that have been used on previous MMISimplementations; these are explained in response to requirement “r” below. However, each RVD andDSD will have Deliverable Expectation Documents (DXD) where the Department will have theopportunity to review and approve the format for rules documentation. Team Noridian’s approach will beto present the formats we have successful used on previous projects as a part of the DXD.8.3.1.2.7 Validating and Verifying Capabilities of the New MMISRFP Section 6.3.1.2, Requirements l, m, nDuring the requirements validation and design process of our iVision360 ISDM, Team Noridiandemonstrates the capability of the proposed systems and solutions, COTS solutions, and proposedmodifications ability to meet the RFP requirements. This process will be undertaken as per the timeframesdefined in the Department approved Project Work Plan.8.3.1.2.8 Detailed System DesignRFP Section 6.3.1.2, Requirement rTeam Noridian’s approach to Detail System Design (DSD) engages an iterative, collaborativemethodology. The starting point for our design approach is our eCAMS transfer system. With eCAMS atthe center, we have multiple cycles of design and review within each business area of the system.Our system design philosophy is consistent with our overall goal for the project; Department satisfaction.This philosophy allows us to use methods and processes that will have an end result that the Departmentconsiders successful. We will approach design using dedicated teams that focus on establishing the DSD ofthe business area, and a separate DSD document will be developed and delivered for each business area.Our approach begins with a completed RSD for a particular business area. Business analysts and technicalstaff prepare the latest version of the transfer solution to be utilized collaboratively during JAD sessionswith the Department. The overall logistics and approach to preparing for DSD sessions is very similar to8 | 67