HealthCare.gov needs less tech, more jugaad

Operators of the beleaguered HealthCare.gov website could take a few hints from Hindu lore and eastern philosophy to fix things, according to two of the architects of the world's most massive national ID system.

FCW discussed the HealthCare.gov's startup problems with Srikanth Nadhamuni, formerly the technology head of India's Aadhaar national biometric identification system, and Raj Mashruwala, who headed up the biometrics development on the project.

They said simplicity is the key to scalability -- and service-level agreements don't hurt either.

HealthCare.gov's creators have faced blistering criticism since its Oct. 1 launch, for drastically underestimating the traffic the site would attract and for the difficulty the site has had in providing even the most basic functionality to users.

In contrast, India's Aadhaar system -- arguably the most ambitious biometric identification and public welfare network ever undertaken by a national government -- is successfully obtaining and storing voluntary fingerprint and iris scans from all of India's 1.2 billion people with the aim of straightening out tangled welfare payments throughout the country.

Since it began the project in 2009, the Unique Identity Authority of India (UIDAI) has signed up 400 million people who submitted fingerprint and iris scans at 30,000 enrollment centers around the country. The project assigns a unique 12-digit number to each participant for their lifetime that serves as proof of identity and residence in the country.

The project is slated for completion in 2019. Like the U.S. health care program, UIDAI's aim is to deliver government subsidies into the right hands, as well as – in India's case -- set the foundation for paperless financial transactions for its users. The data storage needs in Aadhaar are higher than those for HealthCare.gov because it stores images of fingerprints, irises and face photos. Healthcare.gov keeps only textual biographic information and plan choice data.

But, while Aadhaar has been achieving relative success in its ambitious nationwide rollout in one of the most densely populated countries on the planet, HealthCare.gov is struggling to support the daily web traffic many retail websites handle routinely.

According to a study by non-partisan market research company Millward Brown Digital, of the 3.72 million people who tried to register for services on the site from its Oct. 1 opening until Oct. 5, only 32,000 actually completed enrollment. "Healthcare.gov was clearly unprepared to handle the huge spike in traffic on October 1, the start of open enrollment, which the site was visited by 0.9 percent (or one in 114) of everyone online in the United States. This is roughly equivalent to the daily traffic on Target.com," said a statement by Millward Brown Digital. Most consumers who tried unsuccessfully to access the site have given up, it said.

The Aadhaar system is not without its own problems. It has come under fire from India's supreme court because of privacy concerns and enrollment requirements, but technical issues don't seem to be crippling it.

"Why would a far more complex system handling 30 times more citizens go live in 12 months from ground zero and within months handle a million enrollments a day?" asked Mashruwala, a retired executive vice president and chief operating officer at Tibco, a Silicon Valley company that provides infrastructure software to handle Big Data applications for companies such as Delta Airlines, FedEx and Vodaphone. "Jugaad is the operative word," he said, citing a colloquial Hindu-Urdu maxim that roughly means finding an innovative fix or a simple workaround for a complex problem.

According to Mashruwala, the Aadhaar system was adapted to practical real-world realities and the U.S. system would do well to follow that example. For instance, enrollment in Aadhaar is generally kept off line, he said, with online enrollment supported but rarely used. "In a country with spotty high-speed networks, we could not rely on broadband access to 60,000 mobile stations."

Mashruwala was skeptical of reports that the health exchange was bogged down because it needed to do real time checks against multiple systems outside its control. "Personally I doubt that in this age, integration can be an issue. It is most likely bad design, poor understanding and overlooked testing," he said. If the real-time checks are an issue, he advised moving those interfaces off line, allowing for final confirmation a day later, similar to what U.S. Customs and Border Protection already does with application approvals for its Global Entry expedited customs clearance service.

"At the end, it is all about understanding capabilities and constraint of systems one has to use. As Apple has shown over and over again, best design occurs when you understand the user environment fully," he said.

"Keep the design of the system and the citizen interaction simple. Simplicity is the key to scalability," said Nadhamuni, who now runs Khosla Labs, which he formed in 2012 with Sun Microsystems founder Vinod Khosla to focus on solving large-scale problems driven by technology.

He also advised against allowing specific vendors to take such a dominant role that it could become hard to change providers in the future. Another tip: Let users browse and compare plans without having to enter a lot of personal information. 

"We opted for open source and open standards in Aadhaar to ensure low cost of ownership and maintenance as well as to avoid vendor lock-in. This is in general a good approach on government projects," he said. "You can't be religious about open source. Some components may be proprietary but they need to be wrapped with standards and [application programming interfaces] to enable replacement of a specific vendor/component. This approach requires a very high quality government technical team that specifies the solution requirements in greater level of design detail."

Nadhamuni said he would also ensure stringent service level agreements from IT suppliers. "The SLAs need to specify the system traffic and load as well as downtime limits," he said.

The system, he said, also needs rigorous load testing to ensure it won't buckle and all components need to be made independently scalable. "The architecture should allow one to throw extra hardware at the problem as the load increases and should not necessitate a more major software design or code change."