The MMIS Systems Dilemma

White Paper by Rodger Oren, PhD, PMP

The MMIS Systems Dilemma

As the Healthcare community grapples with the Medicaid program, changes and evolution of processes, which adds to the facets of the program, are becoming more common than ever before. If program management was not enough, the computer applications which support Medicaid programs are also increasing in complexity. Changing regulatory needs, such as the Affordable Care Act (ACA) and initiatives from the Centers of Medicare and Medicaid (CMS) like the Medicaid Information Technology Architecture (MITA), add to the Medicaid Director’s list of items which must be considered in their program and computer applications.

Some vendors within the Medicaid program have marketed solutions, updating their Medicaid products with newer technologies. However, the efforts have been plagued with failures. The system replacement projects are generally over-budget, late, and often function poorly. Cost and schedule overruns up to 200% of their estimates are common in the Medicaid sector. When a system update is required, the whole application, spanning all Medicaid business units, is replaced creating a situation where the entire organization undergoes the chaos of a new system.

Medicaid Directors find the Medicaid computer systems difficult to manage. The computer applications are so complex that no single person can fully understand what the application is doing. In an attempt to deal with this situation, the Medicaid computer application has been divided into a series of subsystems, such as Enrollment and Eligibility, Claims, Encounters and so on, which teams of developers work on in their various silos. Working in silos isolates and may inhibit the collaborative efforts. Also, it doesn’t help since the underlying architecture of the Medicaid system is a monolithic construction which makes any work expensive and difficult.

The Solution – Medicaid as a Service (MaaS)

The Medicaid system is composed of various functional silos which are tightly woven into the overall Medicaid computer application. As such, the application is difficult to change, and when changed, often produces poor results due to unforeseen downstream affects within the system. If this were not enough, the application itself is usually written in a computer language and architected in a manner which causes the application to be brittle, making it liable for failure when business changes are necessary to be made within a sub-system for compliance or program needs.

For this reason, Enabling Infrastructure is needed. Enabling Infrastructure allows you to have high-availability with high-flexibility due to its construction. You need to have a contemporary architecture which enables a plug-and-play type of activity, similar to how individual Lego blocks can be removed, replaced and interlocked with the existing structure. This construct allows an organization to update their applications piece-by-piece, which localizes the chaos of a system change effort to a single business unit versus seeing the entire organization in disarray.

The ideal product for this type of Enabling Infrastructure is the Enterprise Service-Oriented Architecture Bus (ESB) product. Fortunately, there are a host of organizations, from proprietary to open-source, which have developed ESB products, several which are running today’s Internet architecture as well as running today’s organizations daily business transactions.

Steps to the Solution

The following outlined steps are suggested in order to plan for and implement a Medicaid application which will comply with the MITA architecture, be modular, flexible and ready for emerging
technologies, such as mobile device use.

Step 1: Obtain an Integrator

The organization must procure an Integrator who is a visionary while able to easily use the technology at hand, such as an ESB. The integrator should also be well versed in Program and Project Management (PM) tools, technique and methods, including using PM Metrics, such as Earned Value and Earned Schedule. Finally, the integrator should be able to grasp and understand organizational behavior and culture in order to successfully implement the change efforts required with modularity.

Step 2: Integrator aids agency in services

The Integrator must have the skills to develop a Service-Oriented Architecture Center of Excellence. This is an essential step in order to develop the ESB charter, methodology, and staff necessary for an Enabling Infrastructure to function in operational environments.

Step 3: Iterative Development – Decide what functional area to implement as a first step

The Integrator, with consultation to the Medicaid Executive Team, decides upon the first functional area to implement Enabling Infrastructure. For example, the team may start with a Provider Implementation, plugging the application in the Infrastructure and then hooking it into the back-end legacy Medicaid application.

Step 4: Repeat Step 3

The team selects another functional area for implementation, such as Claims, plugging this application into the Infrastructure which integrates it into the new applications and the legacy system.

 


© 2015 Rodger Oren, PhD, PMP

Dr. R. Oren has experience managing diverse teams in multi-million dollar efforts creating mission-critical applications, within domestic and international settings. He consults in a variety of industries who have regulatory, organizational, technology and cultural imperatives requiring organizational, program, process and technology solutions. As an Academic, Dr. Oren teaches at several Universities, and publishes articles for the project management, technology and organizational reader in academic and practitioner media.


About The Author

Admin