Can SaaS Software and Healthcare Ever Work Together?
Considering the current mess with the Healthcare.gov website and related aspects of putting wheels on the Obamacare bandwagon, I thought I’d bring in my perspective from complex procurement solution implementations. Since this involves the government, I’ll (somewhat ironically) have to label this a conservative (aka old school) software rollout.
In the procurement software provider space, some of the most old-school prospects are the ones in aerospace and defense, financial services, and – drumroll – healthcare. When I say old-school I mean that they often use on-premise software, running on their own hardware – sometimes even inside their own data center, managed by their own people – or in hardened subsections of Level 4 (exceedingly robust) class data centers.
Stated reasons for choosing this labor-intensive and expensive path are typically that their operations are highly regulated and/or involve content that is seen as too sensitive (personal financial data, health records, intellectual property, etc.)— or even contractually restricted by their clients from placing data on shared hardware in shared environments.
In other words, what they have in common is exceedingly complex specifications – having to meet regulatory, contractual, and external / internal stakeholder needs. To some degree, this makes life easier for the software developers because it makes the use case clearer. They have a solid roadmap to follow.
The caveat lies in the complexity of catering to numerous needs and stakeholders with the power to say no but not yes – especially since hard-coding a process into software often uncovers many areas (decision points) that have been addressed ad hoc. It can take many corporate fiscal years (contractual go-to-market cycles) before everything has been addressed. GPO/BPO solution providers can attest to the complexities of taking over what was previously done in-house. As the experienced outsourcer knows, if you try to outsource something that doesn’t work in-house, at best you will get a “mess for less” that you will have to revisit.
The Healthcare.gov activity has the unenviable burden of having more stakeholders than you can shake a stick at. And no, I’m not talking about John Q. Public trying to sign up for healthcare services. I’m talking about the army of bureaucrats trying to interpret the law (according to CNS News, officials in the Obama Administration “have thus far published approximately 11,588,500 words of final Obamacare regulations, while there are only 381,517 words in the Obamacare law itself”).
This is beyond staggering. It equates to about 15 times the word count in the King James Bible, which contains a mere 800,000 words. How, first of all, this can be turned into a manageable workflow and then encoded in software is hard to imagine, but the nearly half a billion dollars (!) spent so far on the effort shows that the failure is not for want of financial resources.
Judging by the large number of contractors called to testify before Congress, the administration has tried to accomplish this by segmenting the project and breaking it into smaller pieces. But this has only made things more complex.
Seeing how even procurement solution overhauls and extensive rewrites typically take years to launch, involving extensive use case definitions, tests, and then more tests, I can’t see how Healthcare.gov (with its long list of reported problems) can be fixed any time soon, if ever.
What’s worse, assuming it does get fixed, I expect that we will see the mother of all ERP lockdowns after that. Those not familiar with ERP rollouts should know that once the ERP system is up and running, the IT department watches it like a hawk, and non-cosmetic changes almost require Board level sign-off. This is a substantial part of the reason why large companies maintain otherwise obsolete ERP systems, applying more chewing gum and bailing wire as the years go by. Words like dynamic, flexible, and user-friendly aren’t usually used to describe aging ERP systems.
This project is more likely to become a protracted mess for more for the ages, and if it ever gets fixed, the digital Ice Age that ensues will become hard for the “customers” to live with, literally. Does anyone expect that any IT manager will ever touch anything in this site? Talk about a career-ending move if you mess up.
On top of this is the 200-ton elephant in the room that gets so little attention: security. If Edward Snowden could make off with all those NSA secrets, despite the security measures in place, how long before someone gets their sticky fingers on a copy of all the sensitive data that you’re expected to put into this solution? Social Security numbers, financial info, family relationships, not to mention your medical history since childhood… the list goes on.
Even the Soviet Union eventually realized that central mandate (GOSPLAN) approaches to managing the economy weren’t successful. And if the Soviets couldn’t manage the production of tractors, how can anyone expect the American government to manage something as complex and (hopefully) dynamically evolving as our healthcare system?
Time to tear down some walls again! – is what I’d like to end with – however, in this case, some data is clearly best left siloed off and not aggregated into a large pool, so my vote is to get the government out of this business and put some walls of privacy back up.
And you know what, that system works!
- No related articles found