16 Comments

Summary:

According to a New York Times report the decision to go with MarkLogic rather than a traditional relational database was a factor in the website’s rocky debut.

Flipping an old proverb on its head, the Healthcare.gov website debacle has many fathers, at least if you follow  the finger pointing. One of those “fathers” was the choice of a NoSQL database to run parts of the site, according to the New York Times.

Since the problem-plagued rollout of Healthcare.gov, there’s been a lot of blame to go around — between the government’s Centers for Medicare and Medicaid Services (CMS) and the contractors, including CGI Federal, that had to build the site. What I hadn’t heard till now was that the choice of MarkLogic, a NoSQL database may also have played a role. According to the story:

Another sore point was the Medicare agency’s decision to use database software, from a company called MarkLogic, that managed the data differently from systems by companies like IBM, Microsoft and Oracle. CGI officials argued that it would slow work because it was too unfamiliar. Government officials disagreed, and its configuration remains a serious problem.

A report in The Hill  a few weeks back quoted email from Healthcare.gov project leader Henry Chao mentioning MarkLogic in passing. To be fair, the issue seems to be that it’s harder to find database admins and other techies that know NoSQL databases inside and out whereas there’s a ton of existing expertise in SQL databases from Oracle, Microsoft and IBM.

According to Marklogic’s website, it offers the”only government-grade security NoSQL database” and healthcare is a big vertical industry for its software. Neither Healthcare.gov or CMS is listed among its reference accounts.

I’ve reached out to the company for a comment and will update when it’s forthcoming.

  1. The title doesn’t really match the body of the article, does it? Maybe better “How an unfamiliar technology to the team forced on them by an outside entity slowed development” — Not much news with that, though. There’s going to be plenty of excuses flying here, so it would be wise to avoid throwing any technology or product under the bus without specific evidence.

    1. that there are many sources of blame is clearly stated. What was new to me was mention specifically of the choice of databases as part of the problem here.

      1. What was the thesis? Barb Darrow Monday, November 25, 2013

        I agree with Riley. Your article left me with the impression that if they had found someone who knew what they were doing when they configured the DB would be fine and dandy. If there is information to support the headline’s thesis that the tech choice of a noSQL database itself contributed to issues, I missed it in the article. The impression your article left me with was that they selected a minority player tech and then couldn’t find enough ppl who really understood it to get it configured right. It is an argument against selecting minority player tech in general.

  2. It appears it was all about … security.

    Tons of people familiar with SQL = more familiarity among hackers.

    1. nice … security through obscurity?

  3. I’ve recently mused about MarkLogic (you can find it if you try). Beyond the silliness of using a docstore in xml for an OLTP application, is the fact that MarkLogic has been selling its product for a *decade* and still needs to slurp money from the VC hyenas. That’s not a smart foundation for something as important as ACA, now is it?

  4. Oracle’s PR arm sure is busy today.

  5. I hope SmartLogic is throwing its experts at the problem.

  6. Virginia Backaitis Monday, November 25, 2013

    Let’s not throw out the baby with the bathwater. Marklogic is hardly one of the more loved and respected NoSQL databases.

  7. This is US Government work with traditional US Government contractors being paid a fortune to meet an impossible date with no chance of changing scope or time. Pretty sure whatever technology they would of picked they would of found a way to screw it up.

    How many other government IT projects (looking at you FBI Virtual Case File) using “traditional” safe technologies such as Oracle have similarly failed ?

    Although I agree with the concept behind ACA I would never put the US gov and its cast of contractors in charge of building the site. Don’t need to be in the GOP to predict that outcome…

  8. They were saying that it was all about traffic. It is really hard to trace on the roots of the problem because there are so many departments involved. In this case, the administration should take responsibility of the site’s rocky debut. It is hard to trust the country’s health care to this if this will go on.

  9. I suspect MarkLogic’s relationship to Zynx Health was a primary reason it was selected. Zynx Health is a “care plan” development system used by hospitals and other medical facilities. MarkLogic (Zynx Health) has been used for an “evidence-based clinical decision support” system at Cedar Sinai. For example— the DB would help the admitting physician create “care plans” for patients being discharged from the facility. That plan would rely on medical data (“evidence”) collected from the patient during hospitalization. This data could be compared to values (such as DRGs) used for classifying the patient’s diagnoses. The DB would be capable of accessing individual patients’ electronic health records (EHRs) and using it for actuarial purposes to help set premiums in the future. Ultimately clinical data used for supporting clinical decisions and actuarial decisions would be contained in the same DB.

  10. westamastaflash Tuesday, November 26, 2013

    Seems to me that the data being used to make insurance decisions *is* relational in nature.

    A Family has many Citizens
    One State has many Families.
    One State has many Health Plans.
    Health Plans have a set of Subsides.
    Health Plans have Carriers.
    Families, thus, can have a set of health plans given by their state.
    Families “net income” determines the Subsides allowed.
    … et cetera.

    Storing all this data in a NoSQL database seems silly, to me. For the price they paid, a big Oracle or SQL server cluster could handle the load fine.

Comments have been disabled for this post