CA Tech Genius Canot Control Med-Cal Computers

From the California Health Report:

California has greatly reduced the backlog of applications for its low-income health program, but problems with the computer system are still causing headaches for tens of thousands of enrollees.

Programming oversights and glitches have caused the state to send some Medi-Cal enrollees as many as 18 notices in a day, with conflicting messages about their health coverage, said Cathy Senderling-McDonald, deputy executive director of the County Welfare Directors Association of California, a nonprofit that represents the human service directors from each county in the state.

County workers are also unable to delete duplicate applications or remove cases from the system even if the applicants request it.

“Our county eligibility workers need to be able to tell the system, ‘This person is not eligible,’ or, ‘We need to withdraw this application,’” Senderling-McDonald said. “The computer can start that process, but our workers can’t and that was a huge oversight in the programming. We need to deny these 10,000 plus cases that are not eligible.”

The state Department of Health Care Services, which oversees Medi-Cal, is working to fix the computer issues, spokesman Anthony Cava said in an email message.

This I am sure this increases everyone’s confidence in Medi-Cal and California State  IT employees.

About Russ Steele

Freelance writer and climate change blogger. Russ spent twenty years in the Air Force as a navigator specializing in electronics warfare and digital systems. After his service he was employed for sixteen years as concept developer for TRW, an aerospace and automotive company, and then was CEO of a non-profit Internet provider for 18 months. Russ's articles have appeared in Comstock's Business, Capitol Journal, Trailer Life, Monitoring Times, and Idaho Magazine.
This entry was posted in California, Human Behavior. Bookmark the permalink.

3 Responses to CA Tech Genius Canot Control Med-Cal Computers

  1. Dena says:

    Bright kids hired out of school who never worked on a big application in their life. On the other hand, they wouldn’t give me the first look because I don’t have a degree and I haven’t worked on their hardware/software. Getting 100,000 lines of code or more to run clean requires special skills that few have and big data operations don’t have a clue how to look for. A degree protects managements backside because they can point to paper work that indicates they hired the best available but it doesn’t ensure they hired the people who can get the job done. If you need another example you can look at how well the Obama care web site has worked.

    A second issue is they like nice clean structured programs with each module limited to a couple of pages of code. This may eliminate spaghetti code but it instead creates a nested mess that requires you have a very clear map of the system in your head before you can work on it without breaking it. A good deal of code we have run on for years without problems has been spaghetti code and I will be the first to say one should be careful writing spaghetti code, but sometimes the code has to be ugly to work.


    • Russ Steele says:

      I managed a data retrieval project that the mature coders said could not be done, where a team of recent grads, did the job and established the team’s reputation as awesome coders. Some times it takes a fresh look at the problem. That said, it was at TRW who had strong code development process that teams were expected to follow. It was innovation under management control.

      Writing code of the government is hard to do, as the managers keep changing the requirements as the project evolves. When the change orders get out of control the probability of failure increases rapidly. I have seen failure made and it is most uncomfortable. Long story, best told over few beers.


      • Dena says:

        Our unit was a changing product because we started out with only RS232 and a 68000 processor and then added networks, SDLC and Sync communications along with more advanced processors and a improved system architecture. Because the type of data that was moved around in the unit was expanded, the old communication structure in the unit would no longer work. In addition the customer wanted more than hard connection within the unit. To complicate things even more, we had to support the old hardware and continue to have the customers run on the code we were developing because other bug fixes and features were added.
        While we had about 5 other programers working on the initial design, I don’t think there is much code left in the unit that I haven’t gone over to clean the problems the others were unable to resolve, Sometimes fixes were simple but far to often I found myself restructuring the software to correct basic design flaws.
        Then for real excitement, every once in a while a mistake in the assembler would produce incorrect binary. Because the assembler was produced in house, we didn’t have to wait long for a fix.
        Real time firmware can be fun and if not fun, it keeps you employed.


Comments are closed.