What are the IT and Business Implications of Modularity for States?
Steve Larsen:The modularity standard has existed for quite some time as part of MITA. However, the final rule for Mechanized Claims Processing and Information Retrieval Systems (12-2015) is driving increased emphasis and new requirements for states to modularize MMIS procurements. This approach provides several benefits for states:
• Cuts the risk of time and cost overruns and accelerate the implementation of certain capabilities. Modularity also allows for easier upgrades or complete replacement as technologies evolve and program needs change.
• Opens up the Medicaid market to new vendors and increased competition. This can help inject new ideas to drive significant innovation and cost reduction.
• The opportunity to establish capabilities that are needed across the state enterprise, while leveraging a shared funding model.
• Maximum flexibility in deciding the modularity strategy that will work best for their state and their program.
States must balance these benefits of the modular approach with the complexity associated with “too many” modules. In the absence of CMS standards, it may take time for the market to determine the optimal number of modules that will allow for states to easily compare vendor offerings. But if CMS moves forward with a pre-certification process, that will help with standardization and make the market more competitive to the benefit of states.
RW: How do you know if you’re modular?
SL. So far it appears CMS has supported different forms of modularity, some with many modules and some with just a few modules. However, a state’s use of modularity must meet key criteria, including
1. Create downstream flexibility in the event the program substantially changes,
2. Lower implementation risk by cutting big-bang implementations into manageable pieces,
3. Define APIs and architectural standards to allow for interoperability with other modules,
4. Leverage market capabilities that already exist.
CMS has shown flexibility in how they deem a state “sufficiently modular” with their MMIS system. By meeting the criteria above, CMS may view a state as “sufficiently modular.”
RW: What are the IT and business implications of modularity for states?
This is an interesting question and really gets at the core of the modularity debate.
There’s a school of thought that interprets modularity as a “system” feature, meaning, modularity is the degree to which a system’s components may be separated and recombined. But using the definition from the final rule, we see that the notion of “business process” as an integral part of how CMS views modularity. In the final rule, a module 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.” So, a module may meet the CMS definition by being either a “packaged” interchangeable “system” component or a “packaged” interchangeable business process (or set of processes) component. In the latter, CMS opens the door to “business services” as eligible for consideration as modules in addition to system components.
That’s why we see widely varying interpretations among states. We have heard some states are planning as many as nine modules and others planning for just four. The more a state interprets modularity as a system feature, the more modules a state will likely acquire and the greater the need for a systems integrator to tie them all together.
The more a state interprets modularity as a business service component, the fewer modules a state will likely require and the less the need for a systems integrator since the modules have been pre-tied by the services provider. In this case, the systems integrator need only manage handoffs between the services modules and the interfaces to state systems. Another important point for states to consider is that in the “system” interpretation, the state is more likely to tailor the system to existing state business processes, whereas in the “business service” interpretation, the state will more likely need to adapt its business processes to accommodate the services model provided by its vendors. This requires greater state flexibility to modernize its business to adopt commercial best-practices brought by its vendors.
RW: What are additional criteria to keep in mind when determining how to modularize for procurements?
To build on the comments in question two above, I suggest three additional criteria for states to consider:
1. Maintaining accountability: States will need to establish a clear accountability model. States may not necessarily have “one throat to choke.” They will have to think carefully about how to structure service level agreements, interoperability standards and performance measures for the various contractors. It will also require new skillsets from the state teams, most notably, vendor management experience.
2. Cutting risk: The more a state can align its needs around capabilities that already exist in the marketplace, the more a state drives up competition for its business and drives down risk. We call this alignment “commercial modularity.” It takes advantage of the way the market already works, as opposed to forcing the market to transform itself to adapt to how a single state would want it to work. It requires states to be flexible, but will greatly reduce risk.
3. Team capacity and capabilities: All states have made investments in a system. But that doesn’t mean states have to remain tied to updating and maintaining the system through modularity. There are a variety of options – from system to services and to hybrid approaches – that will integrate with existing or new investments. States need to honestly assess their capabilities and decide if they have the capacity to manage a system, multiple procurements, and extensive system integration to build and run a modular system. If a state doesn’t have the capabilities or if the goal is to achieve specific business objectives, a services-based approach is a viable and effective option. Depending on how the business objectives are defined, there could be fewer procurements, less integration, and less management of a system, allowing the state to focus all their resources on meeting their business objectives.
Optum are a Platinum Sponsor at the 2016 State Healthcare IT Connect Summit.
Keynote Panel: Delivering Integrated H&HS: Interoperability, Data & the Enterprise Approach
Moderator:Scott Dunn, Director of H&HS Solutions, Optum
Jessica Kahn, Director Data & Systems Group, CMCS, CMS
Chris Underwood, Director, Health Information Office, Colorado DHCPF
Tracey Wareing Evans, Executive Director, APHSA
Adam Dondro, Assistant Director – Horizontal Integration, California DSS
David Whitham, Assistant ACIO, Health & Eligibility, Massachusetts EOHH
Monday March 21st, Day 01 2016 State Healthcare IT Connect Summit, Baltimore, MD.
‘The Force Awakens’: Accelerating Industry Participation in the Modular MMIS, H&HS Ecosystem
Moderator: Robin Chacon, Healthcare & Human Services Practice Director, CSG Government Solutions
Ron Baldwin, CIO, State of Montana
Jessica Kahn, Director Data & Systems Group, Center for Medicaid and CHIP Services, Centers for Medicare & Medicaid Services
Kay Hallawell, Sr. Solution Director, Optum Government Solutions
Chris Lunt, VP Engineering, GetInsured
Pradeep Goel, CEO, EngagePoint
Chris Greene, Associate Vice President, Business Architecture, Molina Medicaid Solutions, Molina
Tuesday March 22nd, Day 02 2016 State Healthcare IT Connect Summit, Baltimore, MD.