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 heard the word ‘modularity’ countless times during my first few months and here was an entire community struggling to define/interpret/implement it.
The word “modularity” appears in federal code across what is called 42 CFR [Code of Federal Regulations] and is defined as “a packaged, functional business process or set of processes implemented through software, data, and interoperable interfaces that are enabled through design principles in which functions of a complex system are partitioned into discrete, scalable, reusable components.” That is a fine definition by all accounts, but modularity inherently is an abstract concept that you commit to as a journey guided by more fine-grained principles and it can be a hard to make it an objective goal for purposes of compliance. It struck me as odd then that modularity found its way into regulations that govern state Medicaid IT systems. The regulators intentions were grounded commendably in forcing antiquated monolithic state systems out to allow for easily replaceable, scalable component or services based systems that are able to meet the fast changing demands of the Medicaid program and keep up with the technology trends. And of course the collective consciousness of the Medicaid IT ecosystem — State Medicaid IT leadership and the vendor and consultants — tried to turn modularity into an objective measure because everyone loves objectivity (right?). It allows for states to check the box on a federal regulation and allows a vendor and consulting community to sell ready solutions that promise attainment of that objective goal.
It is no wonder then that “modularity” and its definition was debated upon within forums as states struggled to understand what CMCS meant when they ask for modular. The vendor community serving the Medicaid market represents an interesting specimen within enterprise software companies in that it has historically been an ecosystem that builds one-off custom solutions built off of 200 page RFPs with 1500 requirements. When the call for modular was heard there were a few different types of reactions from the vendors: a) status-quo, until states ask for something different, b) package their own solutions as modular because they can “potentially” be delivered as smaller business process categories (notice that I added the word categories, because that is how the vendor community chose to package them) c) truly build a modular, scalable solution with open interfaces from the ground up. Most reactions fit into the second bucket and hardly anyone wanted to do the last one, as that did not represent the dynamic of vendors within this ecosystem. Imagine a space where innovation is largely absent because vendors don’t push ahead and offer something new. There was too much risk to build it right from the ground-up because they did not think states knew how to ask for something new — using a different procurement strategy and lens.
After my initial time within the forums for states and vendors, including some of new ones that were formed specifically to help everyone solve the modularity puzzle, it became clear that everyone wanted to work largely within the confines of the current processes, under similar constraints and only representing delta improvements that might allow the constituents to claim modularity but were going to be far from offering any real tangible benefit of cost savings and agility. One of the things that I identified in reading the new state RFPs that were coming out was that the states didn’t know how to ask for something different. And if truly this was going to be driven by the states we had to provide them with a language and a process to ask differently. Ideally, we would also have the vendors involved in it as well so that the states could feel confident that the vendors would actually be able to provide what they ask for. To understand this think that almost everyone within this ecosystem is extremely risk averse and resistant to change. Except the current way of doing things hasn’t worked well — most Medicaid IT projects were multi-year commitments with long RFP and development timelines. In effect by the time systems were operational they could be 2–3 cycles behind in terms of regulations and technology.
While we were hashing out what a pre-certification program for Medicaid modules would contain we kept running into the need for automation and objectivity within such a process. The system certification process comprised off a manual checklist at inconsistent levels of granularity. There was need to introduce objectivity with pre-certification for some functional standardization. So we came up with the notion of a reference architecture comprising of a library of defined interfaces at a sub-process or component/service level that would utilize standard data exchange elements where they existed and posit the creation of standards where there were none (also something that ONC was interested in, but more on that later). This would not be an actual implementation but set of granular service definitions that a particular module would need to implement. An actual implementation could then be verified to be compliant based on its ability to pass data in and out as per those service definitions. This was nothing new; it was how most scalable plug-n-play architectures had been designed through the use of open APIs. We deliberately chose to ignore the problem that a lot of the forums were struggling with — module definition — which was being thought of at a business process category level, was in line with existing checklist driven system certification process.
I should address why I thought that module definition was the wrong problem to solve. In one of my previous posts in this series I had made a mention of the Medicaid Information Technology Architecture (MITA). MITA had not been revised for many years and provided guidance on Medicaid architecture at the business process level, however there were a lot of details around information architecture and technical architecture that were missing. State RFPs for modules bundled MITA’s business processes that made sense to group, sometimes for logical reasons, sometimes for convenience of implementation or for the sheer lack of prescription, to define sub-systems that they put out to bid. The Medicaid system certification process had also evolved to offer modular certification but it had also provided this under logical bundling of MITA processes. Most RFPs that I came across tried to align with one of the logical bundles part of the certification process. If you picked up an RFP that used one of the module references from the system certification process and compared that to another RFP similarly referenced, you would find significant differences in the functional requirements (not to mention UI/UX, architectural, security and services. That’s because the same set of features and business processes can be implemented differently. Often the requirements would break the cardinal rule of requirement writing and start to include “how” details within them. Hence two state RFPs essentially asking for the same thing on the surface will get significantly different, i.e., custom made, solutions. This method of aligning with just the business process categories but diverging at the service/process/sub-process level had made it very hard to get re-use, as the outputs (which is mostly what the current system certification process measured) had internal dependencies on the environment, including specific workflows and human sub-processes.
Our decision to decompose the traditional MITA business process or area was important because a single business process category has one or more business processes and they in-turn have one or more sub-processes. To achieve reuse you need to be able to get down to functional components and services, which can only be achieved at a sub-process level. It was also important to frame this is an evolution of MITA so that MITA could stay relevant in the world of Agile development and micro-services based architectures that allow independent resource scaling, continuous integration, continuous deployment, open APIs and live analytics. Lastly, it was also important that this has equal buy-in both from the buy and sell side. Hence an initial cohort of states and vendors were selected with ability to commit technical resources towards producing service definitions as per their area(s) of interest. The service definitions had to follow an architecture definition standard that was in line with by Department of Defense Architecture Framework (DODAF), UML/SysML and other IEEE standards. There was also a notion of a base services layer, which accumulated service definitions that had potential of reuse across more than one functional area. Soon we had active participation from over a ten states and vendors and readouts that included over 50 other participants.
I feel this work on providing a reference architecture, code named Poplin, and the thought process that it invokes is a necessary ingredient in achieving the long-term goals that CMCS had set forth. It was less about being prescriptive but more about achieving alignment on tangible steps and deliverables that the participants produced themselves that would help them and the community at large. I hope to see this carry forward and provide guidance to the community and evolve MITA to keep it applicable for the next generation of state Medicaid IT systems.
This article first appeared on my LinkedIn blog — https://www.linkedin.com/pulse/need-common-language-reference-architecture-medicaid-anshuman-sharma/