|
Videos
May 12, 2011 By David Raths
If Handler from Illinois is dissatisfied with the traditional MMIS procurement process, he has company in Steve Fletcher, CIO of Utah, which is currently weighing its options for MMIS replacement.
“These systems cost on average about $120 million, and that is outrageous,” Fletcher said. “Many vendors build these systems from scratch, and basically it’s mainframe technology. That’s why they get this pricey, and I think it’s the wrong way to go. If someone would offer me a transactional service so I don’t have to build it, I would be very interested.”
Fletcher said he has spoken with federal CTO Aneesh Chopra and CIO Vivek Kundra about this topic. “It drives them crazy that there are 50 MMIS systems,” he said.
But Fletcher stressed that if the federal government wants states to change, it must provide different incentives to the program executives. “The CIOs get it,” he said. “But on the business side of Medicaid, they hear that the feds are going to provide a 90/10 match to do something, and that sounds pretty good to them, even though we have to pay $12 million.”
If Utah creates an MMIS with another state, the federal match would only be 50 percent, he added, so the state Medicaid business people see that as proposing something that will cost around $20 million more, even though it saves money overall. “I think the incentives have to change,” Fletcher said.
Danes from CSG Government Solutions noted that her firm is working with North Carolina, South Carolina, Tennessee and Georgia on a feasibility study for procuring a single unemployment insurance system that each state could customize. “If we can develop a set of best practices there, perhaps we can bring that over to Medicaid,” Danes said, although she added that it’s tough to work through governance and ownership issues.
Officials in Arkansas echo Fletcher’s cost concerns as they begin an innovative — and abbreviated — MMIS procurement process. “We expect to fundamentally change the health-care system in Arkansas, and the MMIS by definition has to be changeable and agile,” said Gene Gessow, director of the state’s Division of Medical Services. “We are not going to buy a design/build system. We can’t afford the time or the risk.”
Time is critical due to mandated changes to Medicaid, ICD-10 deadlines and the contractual end of the existing MMIS contract. The state’s MMIS procurement strategy calls for an ambitious one-year development cycle followed by six months of testing. It expects the shorter implementation time frame will be possible because a systems integrator will create the MMIS by assembling loosely coupled “best-of-breed” modules that already exist rather than creating something from scratch. Gessow stressed that Arkansas is interested in hearing proposals from vendors new to the Medicaid environment.
State CTO Claire Bailey said that unlike some states, Arkansas does not yet have a functioning health information exchange. “But that is good in the sense that we don’t have to retrofit anything. We can look at it with fresh eyes,” she said. “We envision a common portal for the health benefits exchange, the health information exchange and the Medicaid system. We think it makes sense to use a core set of solutions for all these purposes.”
Bailey realizes that Gessow’s ideas are innovative and his timeline ambitious, but she is optimistic that it will get done. “We need the vendors to step up to the challenge of delivering this on time and on budget,” she said.
You may use or reference this story with attribution and a link to
http://www.govtech.com/pcio/New-Approach-to-Medicaid-Management-Information-Systems.html
Collaborative Justice: Transforming Criminal Justice Services Through Unified Collaboration
Cloud-Based Services Accelerate Public Sector Adoption of Video Collaboration
I think that many people are misguided by the tag ‘Legacy’. While the software may be old the operating systems and database engines that run on mainframes are not old. As a matter of fact DB2 runs circles around any server based system in speed and reliability. I have been told, since the advent of server technology’ that mainframes are a thing of the past, that was 20 or so years ago. This notion that you have to get rid of mainframes is non-sense. The idea of 'cloud computing', which is little more than a new way to say outsourcing, being the solution to this problem is equally non-sense. I believe the way to go is to properly utilize mainframes and use them as extremely fast and reliable file servers. The server environment is not conducive to processing large databases and I think you all know this. I have been in the business for over 30 years and I can count one 1 hand the number of times I have seen a mainframe 'go down' other than scheduled maintenance. Can any of you say the same about the server world? In short, the mainframes are already there, they are already being paid for, you are not going to be able to 'get rid of them' any time soon, so utilize them and take advantage of what they do good and shift what they do bad (user interface) to the server world. It will not only save money in the long run but will provide faster and more reliable computing. I encourage any of you to explain to me how I am wrong, please I love a good argument and I love even more ideas better than my own.
About thiws comment '“MITA is pushing states toward a more component-based system and away from mainframe architectures,” said Dan Sisco' Mr. Sisco, are you trying to assert thet component based or modular systems and the mainframe are mutually exclusive? Really? Then I assert you don't understand the concept.
My apologies, Should always proof read before hitting the submit button. About this comment '“MITA is pushing states toward a more component-based system and away from mainframe architectures,” said Dan Sisco' Mr. Sisco, are you trying to assert that component based or modular systems and the mainframe are mutually exclusive? Really? Then I assert you don't understand the concept.
Well...maybe not mutually exclusive but I think modular systems are much more difficult to develop within a mainframe ecosystem. And all the ancillary/3rd party applications are fairly hard to integrate. To me, Java and .Net apps, web services, etc. are the way to go. Lot's of "Sisco/Cisco/Sisko's" commenting here. :')
I think the biggest problem is that systems like Oracle, Tera Data, SQL Server et al, cannot handle very large databases and they cost more to boot. My model is to use the mainframe (if you alredy have one) as a very fast file server with DB2 as the database engine. The only programming that need be done on the mainframe (in this model) are the batch updates and other maitenance. The Business rules and GUI applications would still be (and should be) in the server environment. it is a simple solution to many complex problems and I don't see why more IT people do not recognize this. The only reason I can see is that the people making the decisions do not have a real grasp of the problem and that the people they do listen to are either the vendor sales people or their own IT people who are just enamored with new rather than right. PS - The e-mail I am giving here is to a guy who has done extensive work on the geneoloy of the Cisco/Sisco family tree phsisco@gmail.com
From the ICD-10 deadline to the need for medical scribes, the hurdles facing EHR implementation are numerous. http://www.healthcaretownhall.com/?p=3858
Just think of mainframes as servers on steroids. All these guys who learned the business in the past 15-20 years think this is new stuff. The fundamentals are the same. Keep it simple. Today's architects love techno-speak, elegant solutions with the latest technology and moving parts. Unfortunately, the moving parts usually mean up and down. Touch one part of these complex architectures and you'll understand how much fun it is to watch the dominoes fall. You could learn something from us "legacy" guys.