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. I had never worked in Medicaid before so I want to talk about my first few months in the role and the ensuing abbreviation soup!
Before I started my role, I had a chance to talk to previous EiRs to level set expectations. Not only was Medicaid going to be new to me but so was working for the Federal government. With a lot of new territory, I had to give myself enough time to understand the lingua franca and immerse myself. At the same time, I knew that the EiR term was time limited. It took me the better part of the first four months to understand this new ecosystem which comprised of CMCS leaders and system owners; State Medicaid leadership, IT and program staff; large Enterprise IT vendors and some healthcare specific solutions providers and various flavors of consultants to plug the holes in skills.
The first few months I was on “sponge mode”. I conducted informational interviews with anyone that was introduced to me. Sat in on weekly and bi-weekly conference calls, which were conducted for variety of audiences and purposes. These ranged from forums for State Medicaid IT leadership to present their initiatives and for others to learn from them; CMCS Medicaid IT program leadership and their regional representatives; an all encompassing human services vendor forum; and a few forums that had participation across federal, state and industry membership. There were so many different forums with similar themed discussions. How would one chose to participate in some and not in another — as a state Medicaid employee or a vendor? Some of these groups had long histories and were established by leaders in the Medicaid IT space. I questioned the need for their continued existence in the face of industry transformation and the need for these forums to either sunset or evolve to still create value rather than noise. It often seemed like a turf war being played out to serve the same type of audience to the dismay and ongoing confusion of the audience.
Apart from my own confusion around the value of these forums and what type of audience they served best (which as a matter of fact I was asked many times by new members to this ecosystem that I came upon — vendors, state Medicaid IT folks — who thought that somehow after a few months I had become an authority on the subject), there was also the matter of understanding the jargon of Medicaid IT; regulations, implementation and processes, through which Medicaid IT projects came into being. The SDLC for Medicaid IT contained within it its own abbreviation soup. During my sponge mode I kept a running list of the acronyms thrown around which I would then read up on to get more context. Some of these came from the federal processes for approving funding for new development (or maintenance) projects and approving the operational state of these systems, while others came from the Medicaid IT enterprise systems terminology and decomposition. In addition to these, the SDLC process could also vary based on the procurement and RFP side from state to state, due to the nature of how Health and Human Services (HHS) were organized within a particular state or due to regulatory constraints (both of these are extremely important considerations as I realized often in trying to bring a change within this ecosystem one runs into inertia up and down these organizations). I quickly built appreciation for why this niche enterprise software market had its own specialists that could help navigate all the additional complexities layered on top of the standard SDLC. I will attempt to demystify some of that here.
Little context about this enterprise environment first. Medicaid IT is a niche healthcare market that comprises of solutions provided to states and territories, to administer Medicaid acting as a payor, by a vendor pool that consists of some of the biggest names in enterprise software solutions and services and others that are well-known government contractors. The Federal government provides states sizeable funding match to develop and maintain these systems. In turn the Federal government institutes a process for approval of funding, and certification of these systems that guarantee the systems function in line with federal requirements and regulations. These systems have historically been divided into three sub-systems primarily to align with federal funding lines and programs. These are Eligibility and Enrollment (E&E), Health Information Technology/Health Information Exchange (HIT/HIE) and Medicaid Management Information System (MMIS). Within these the E&E and HIT/HIE systems have broader utility to a state HHS reaching beyond the Medicaid program. They often involve other federal agencies or state HHS agencies (such as other need based programs SNAP/TANF or public health) based upon the project. CMCS has instituted the Advanced Planning Document (APD) process for states seeking funding (I will refrain here from going further into stratification of funding, federal match, and other federal and non-federal sources for full cost allocation of a project which the states have to align with while preparing their ask).
The APD process is widely used across HHS federal agencies interacting with their state counterparts. There are two types of APDs — one for planning and the other for implementation. Depending upon the context, i.e., regulatory compliance, state goals, etc., one or both can be used. The context of the APDs typically aligns with one more Medicaid business processes part of the Medicaid Information Technology Architecture (MITA) guidance by CMCS. These business processes are similar to what you would find operationally at a payor — provider enrollment and management, member management, claims processing, third party liability, fraud waste and abuse, etc., I found the MITA guidance to be dated and it was good to see the establishment of a governance board for MITA to keep it relevant and make sure it gets updated to be in line with the changing healthcare landscape and evolution in architecting enterprise systems.
Approved APDs allow the states to utilize Request for Information/Proposal (RFI/P) to work within the state’s procurement laws to issue a CMCS approved RFP into the vendor community. The RFPs issued by states often allude to the state specific procurement constraints that I found to be extremely stringent and counter to success in a complex enterprise environment. In fact, state procurement and its handicaps were often a topic of discussion at several forums that I participated in and even at Medicaid conferences. Most Medicaid IT staff and their consultants continue to churn out these stringent RFPs detrimental to the Agile development philosophy. Once a vendor is selected they take on the development and implementation with Federal oversight through the regional centers.
States vary in their resources and capabilities, and SDLC functions pertaining to PMO, architecture, QA, IV&V and system integration are all outsourced to different vendors that work with the functional vendors to bring processes online. Post implementation the state and vendor(s) combine to take part in system certification reviews by CMCS as a seal of approval for the system. This is done through the Medicaid Enterprise Certification Toolkit (MECT) — a checklist based audit process, which tends to be time consuming for all parties involved. This certification process focuses mostly on business process outcomes but also has functional and quality based metrics. The pre-certification program that is in the works is meant to compliment this and provide additional value once adopted by states and vendors.
I’ve tried to summarize all that I was exposed to in the first few months to provide context of the environment I was stepping into. It definitely was overwhelming and far more of its own universe than I realized going in. Through all those forum and one-one-discussions I realized the constraints under which these systems had been developed and were still being developed even though some of them needed to get re-evaluated, relaxed and sunsetted to allow Medicaid to take advantage of modern modular enterprise systems and best practices. The drumbeat of modularity was heard through every discussion and conference session and for some reason it was being looked upon as this uncharted Wild West instilling fear and anxiety. The pre-certification process would be just one piece of the puzzle, and a lot more would be needed.
This post first appeared on my LinkedIn blog — https://www.linkedin.com/pulse/business-medicaid-systems-making-sense-abbreviation-soup-sharma/