When either the California ePedigree law or the federal law go into full effect, how smooth will that rollout be? While there are big differences between those implementations and the deployment of Healthcare.gov, the U.S. federal government’s new health insurance exchange website that is part of the Patient Protection and Healthcare Affordable Care Act (often referred to as the ACA, or “Obamacare”), I think the troubles it is experiencing may be an example of how the ePedigree system will work on initial rollout. That’s right, I’m predicting a nightmare, especially if it’s the California law that rolls out.
I am a small business owner with no employees other than myself. For the last 16+ months I have been using the health insurance from my previous employer, Cardinal Health, which was guaranteed by the Consolidate Omnibus Budget Reconciliation Act of 1985, commonly known in the U.S. as “COBRA insurance”. It’s been great. While I pay the full premium every month, it is a high quality plan through a high quality insurance company. The only problem is, Cardinal Health is obligated to offer it to me for only 18 months after I departed their employment. That would cover me right up through December 31, 2013. The earliest Obamacare coverage can start is January 1, 2014. Isn’t that great timing?
And so I am very interested in ACA coverage, costs and quality. As everyone in the United States is aware, the Healthcare.gov website became available in early October for individuals and small companies to sign up for coverage next year. The rollout of the site has been a nightmare with only a small percentage of people being able to complete their applications and lock in an insurance policy because of software bugs. It has turned into a huge scandal and those opposed to the ACA are trying to use its troubles as a means to damage the entire insurance program even further.
MY EXPERIENCE ON HEALTHCARE.GOV…YEP, IT’S BROKEN
I waited until last Thursday night last week to try to logon, waiting until 10:30pm EDT in the hopes that it would not be overloaded with others trying to hit it, but that wasn’t sufficient. I couldn’t create an account. After a long delay it asked me to come back later.
So I tried again Friday night at 10:00pm EDT. It turned out, my account had been created the night before, it apparently just couldn’t tell me that. This time I was able to login and fill out an application. I got as far as being able to review all of my data entries and digitally sign my application. I thought I was set. Even the home page after I sign into the site now said that my application was “In Progress”. Great right?
Well I did some searching around the internet and it appears that “In Progress” means that you are still in the process of filling out your application, not that the application review process is “in progress”. Kind of confusing. You can click on the indicator for your application and review and edit all of the data you’ve already entered. You get duplicate questions and you even get duplicate choices under some of the same questions you answered before. You can sign it again. But it never gives me any “submit” button so maybe one of the fields does not contain valid information and it just isn’t telling me which one…perhaps. It feels like I am caught in an infinite loop.
Is my application complete and will I eventually be given choices for actual plans? Am I simply confused by the user interface (it is really confusing)? I have some new ideas based on an article I read that may explain why I thought my application was incomplete (because that’s apparently what it implies to everyone, even when you are done). I’d like to login and try something different but the website is not available today at all (seems there are some fixes being applied right now). One fear I have is that my data is corrupt and when they fix the bugs I hope I can start over and fill out a new application. According to the government timeline, I need to select an insurance plan by December 15 to be covered on January 1. We’ll see.
WHAT DOES THIS HAVE TO DO WITH ePEDIGREE?
The bottom line is, the Healthcare.gov site was rolled out based on an immovable timeline rather than after the software was fully tested and working. Does that sound familiar? January 1, 2015 is only about 14 months away and it is immovable unless Congress passes a federal law that would preempt it. While that is a distinct possibility, time keeps chipping away and preemption hasn’t happened. Few companies are on track to be ready with the needed systems.
Of course, the big difference between Healthcare.gov and California ePedigree is that the former depends first on the successful operation of a single government-deployed website and then the systems of many insurance companies. But those systems at the insurance companies are not new or radically different from the systems that they have had running for years, so Healthcare.gov is the stumbling block. All the insurance companies need to do is create an interface that will receive and interpret the standard insurance application collected by Healthcare.gov and then respond with one or more policy offerings. That interface produces “interoperability” between the government run website and the insurance companies.
In the case of California pedigree, the state chose not to get into the business of defining interoperable interfaces. They left that up to the industry to figure out, and the industry “chose” to align around GS1 US Healthcare to define the interoperable approach. GS1 Healthcare and the industry chose an approach that was interoperable in theory, but is not known to comply with the law (see “The Board of Pharmacy Must Respond To Ideas For Making EPCIS Work”). And another problem is, few companies have tested the data exchange to confirm that it is truly interoperable. And those who have done so report that it has never worked the first time. In fact, it often takes some negotiation and changes by one or both parties, and lots of retesting.
In the case of Healthcare.gov, HHS has instituted a “tech surge” to swoop in and fix the problems. That may or may not work for them, but I am confident that approach won’t work in 12 or 24 months for the California ePedigree law because there won’t be any people sitting around who know what to do. EPedigree knowledge is not nearly as common as website, user interface and database knowledge. Thousands of companies will likely need help at the last minute, and the needed surge will likely be just the opposite.
The real test will come in July of 2016, if the California law is not preempted. That’s when the wholesalers will have to decide which products they will be willing to distribute, and which they will not because those products are not compliant in their eyes (see “Who Will Decide Which Pedigree Model You Will Invest In?”).
Imagine what will happen on January 1, 2014 if I still can’t get insurance because Healthcare.gov still has a problem. My wife and I will not have health insurance and so we will not visit a doctor, clinic, pharmacy or hospital unless we are dying. Fortunately we are in good health, but others won’t be so lucky. Now imagine what will happen on July 1, 2016 if the wholesalers in California decide that only some of the drug manufacturers have prepared sufficiently that they won’t get fined for carrying their drugs across the California border. If that happens, a lot of people in California won’t get their drugs. That would be a real nightmare. (For an alternate scenario, see “Will The California ePedigree Dates Slip Again?”.)
I am growing increasingly pessimistic about the California situation. Better cheer myself up by focusing my imagination on what might happen if the Senate passes H.R. 3204 without amendment… Ah yes, that’s better. All I see are roses.
One thought on “How Smooth Will Industry Deployment of the ePedigree Laws Be? Take a Good Look At Healthcare.gov”
Good comparison and the usual result of fixed dates as opposed to fixed standards. By the way, it seems we still lack standards at certain key points of where serialization is supposed to occur beginning with systems which print, log, and verify use of codes at line level.
Comments are closed.