Part 4 - Iowa Medicaid Enterprise

RFP MED-12-001 | Technical ProposalIowa Medicaid Enterprise System Service Procurement | MMIS and Core MMIS OperationsTeam Noridian also understands the need toconvert legacy data into the new MMIS and hasexperience converting both current and historicaldata into MMIS production systems and datawarehouses. This understanding is wellrepresented in Team Noridian's implementationsin other states, which included very large datasets extracted from a variety of legacy systemplatforms. Team Noridian's approach toconversion planning is the critical step thatprovides the roadmap for the conversion effort byidentifying all the sources of conversion dataand laying out a plan to design, implement, and test the conversions.Once the conversion plan is in place, the conversion tasks begin the process of designing, developing, andtesting the conversion. The mapping effort is the most critical activity as it will define how the data isconverted into the new system. It must be emphasized that the conversion team cannot perform thismapping in a vacuum. It must be a highly integrated process with the application development and stateteams. The application development team understands the target system and the existing system givencurrent support for the Department. With a thorough understanding of both the source system data andtarget system structure, we minimize the risks typically involved in data conversion. This, coupled withactive participation of the Department, will provide the required foundation to produce error-freeconversion. The conversion team’s job is to bridge the gap between the two systems and make thetransition seamless from a data standpoint. Wherever possible, the conversion team will usedocumentation from existing legacy systems to aid in the mapping effort. In addition, the conversion teamwill work with the state to fill in any gaps in the documentation.Once the mapping process is complete, the exception reporting process becomes critical to identifyexceptions to the rules. It is natural that many nuances in the data will only be revealed once the legacydata is in the hands of the conversion team and the conversion programs are being developed. Theexception reporting process is designed to identify the gaps and misalignments in the converted data sothat action can be taken. Since the conversion process is highly iterative, the exception reporting processbecomes attached to conversion at all points forward. The conversion is not truly complete until theexceptions reports report clean data.Once the conversion programs are developed, the conversion testing phase will begin. The key tool inconversion testing is the validation report. The validation report compares the actual conversion results tothe expected conversion results and identifies discrepancies in the conversion. The report becomes criticalin identifying data to be cleansed or conversion rule changes needed. The validation will be firstperformed at a unit conversion level and is scalable to full module and system level conversion tests thatare done in later phases of testing.Application level testing efforts are also critical to the conversion testing activities. The system users willplay a key role in validating that the conversion has resulted in proper application function. This can beexecuted as part of conversion UAT as well as during functional UAT to ensure that conversion isworking as per the conversion design and within the requirements of the application. Because all dataelements may not be easily validated through front end screens, additional validation will be performedon the data when it is extracted and loaded to the data warehouse.When the final production conversion occurs, it will rely on the foundation built in the prior phases. Theconversion programs will run and the results will be measured by exception reports and validation reports.Once the counts, exceptions, and validations are all reconciled, the conversion will be declared complete.8 | 105