By skyforbes 
Continuing the multi-part series highlighting my work as an Entrepreneur-in-Residence with the Center for Medicaid and Chip Services (CMCS). Would love to hear from others that have experience in similar stints with the Federal Government or within the State Medicaid space. While the need for how systems were built and implemented was important for CMS what was not lost on me was the fact that to truly embrace the change the organizations running these systems also had to adopt new processes and commit to organizational change.
The Federal Financial Participation (FFP) funds available to states come with reporting requirements that align with the Advanced Planning Document (APD) process. This is not quite a stage-gate process but something that federal entities use with different HHS agencies on the state side. For Medicaid, The APD process, as I have previously discussed, involves approval from CMCS, after which the states issue a Request for Proposal (RFP) and sometimes a Request for Information (RFI). I found out that RFPs are often written by consulting organizations that states employ and routinely take over a year at times. These result in documents with thousands of requirements that are routinely two hundred pages long. In addition, they often contain stringent language owing to the procurement processes and regulations that the states follow. In reviewing many such RFPs I could not find a clear connection and alignment between the needs, goals and buying/building of expensive IT systems. During my initial months, listening in on the forums with state participation, I came to realize that while states were eager to transition their systems from the legacy “big bang” implementations, their internal processes were still tuned to build and manage monolithic systems, where a single vendor (often referred to as “one throat to choke”) spends a decade building a custom solution and then operates that for another two. Moreover, it seemed that beyond the writing and putting out of RFPs, it wasn’t clear who owned the process(es) that were meant to be upgraded (or added) as a result of an implementation, or what was expected as a return on that investment. Imagining this happening across multiple simultaneous modular procurements that the states envisioned to undertake and it seems too much to expect to go right utilizing processes that had failed to deliver on monolithic procurements.
Being an outsider to Medicaid, this struck me as far from ideal. The existing processes had resulted in major failures at the states causing delay in operationalizing systems and cost over-runs. I was offered a chance to team up with a couple of passionate Medicaid veterans from the state and federal side to ask a set of questions. What if we were not encumbered by the current APD processes and could reimagine a more efficient process that offered more transparency, accountability and was ideally suited for modular system implementation? What would that look like?
We wanted to bring some discipline, transparency and accountability to the decision-making at the state level when it came to undertaking technology projects that served policy or administrative goals. We called this the Medicaid Business Model Framework. This was divided into five different steps each with an artifact that reflects the work done to increase transparency. Borrowing from best practices such as business model canvas we wanted to allow leadership at the state level to be able to visualize the mapping of organizational goals to technology spending so the RoI question can always be answered satisfactorily. Since Medicaid isn’t a single program but a conglomeration of multiple programs serving multiple segments of the population, we can think of these as separate service/business lines. The business processes serving these service lines follow the MITA nomenclature. An organization pursuing key goals should be able to identify clearly which business line(s) and business processes are called into focus with each goal. There is also need in constructing the goals so they are objective and progress can be measured against them.
The next step in the process is to do a lay of land for what was already in use within a state. This represents assets — infrastructure, technology, and services — that the state already possesses or is using to support on-going efforts. This assessment needs to be done periodically, similar to the goal matrix above, to be able to ascertain the current state of assets, assess upgrade or obsolescence and any potential re-use for new initiatives. Depending upon the purview of the enterprise architecture practice within a state, this could happen at the Medicaid, HHS or the entire state enterprise level. If there is no enterprise architecture practice, this should happen at the Medicaid level at a minimum. After assessing any potential assets or capabilities that can be re-used the procurement of complimentary solutions that are needed should be attempted. This is perhaps the hardest step in this process because it carries with it huge amounts of organizational inertia, risk aversion grounded in outdated practices, and statutory hurdles. Needless to say, it is important to slice procurements as finely as possible to allow for point solutions that require no customization to be procured as licenses. Any custom development needed then should be attempted as part of a services contract. It is important to decouple the product and solutions procurement from the services procurement to give the organization the greatest freedom in deployment, on going maintenance, and use of complimentary services (such as tech and workflow support) that might be needed. There is a real problem in issuing out RFPs that include everything but the kitchen sink within them.
So far I have covered process changes around technology projects on the state side. The last two steps we envisioned involve changes on the federal side, and represent a departure from the IAPDs/PAPDs based process. The APDs we reviewed lacked any context around the strategy or goal that it supported or information on how it fit into the state’s overall technology spend in the near and medium term. While some of this would be clear to the state if they completed the first step in this newly envisioned process, the overall context and mapping to organization goals for any project is equally important to the federal funding entity. This is especially true for any multi-year or multi-entity projects (anecdotally, this was around 40%), where more than one federal entity is involved in the funding. This formulation of the federal funding request would provide a comprehensive picture of all technology projects, spends, cost allocation and progress made along milestones.
The last piece of this process was meant to provide some objectivity and data-driven decision making to CMCS itself. CMCS wanted to represent smart money, and people that write smart money checks (horror stories of Theranos aside), whether this is on the corporate side or on the venture capital/private equity side, employ a project portfolio management approach that includes risk management built into their decision making process. While CMS can’t quite behave like a true VC (it can’t just flat out refuse a requested investment), it can ask a state to adjust its ask. This adjustment is the focus of the last step. Funding state projects should be based on data from a state’s consolidated funding request and data coming from other states and how they have faired against their asks in their funding requests. Assignment of a risk score to each project based upon a template, and that template made public to states can allow states to understand the rubric for risk assessment.
This new process and methodology was presented at all CMCS/state forums and at the Medicaid conferences. Finally, two states were selected to go through a dry run of this new process. While we weren’t able to take a project at a state through this entire process there was enough feedback from the states on the utility of the first step. The technology assessment was harder to do because of lack of enterprise ownership and buy in. While the aligned procurement strategy was not attempted as it represented the most significant change, it is also where the execution needs to evolve to change outcomes. On the CMS side there was feedback on the utility of the evolved federal funding request but the risk assessment (even though it was proposed have transparency) was not received well. However, there was clear need to continue this very important work even though it represents a significant change to both states and CMCS. There is a strong case to rollout some of these in a piece-meal fashion and even evolve them individually, at least the ones on that involve just the state to fit their organizational structure.
This post first appeared on my LinkedIn blog — https://www.linkedin.com/pulse/change-only-constant-need-state-medicaid-systems-adapt-sharma/