Blog Post

How the use of a NoSQL database played a role in the snafu

Flipping an old proverb on its head, the 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, 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 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(s orcl), Microsoft(s msft) and IBM(s 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 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.

16 Responses to “How the use of a NoSQL database played a role in the snafu”

  1. I am a developer and have used MarkLogic in production and it makes a great database for the online data tier of a web application. There are a lot of uninformed talking heads making a lot of noise around this story.

  2. Lets not try to play blind men and the elephant here. The article states that MarkLogic is used in “parts” of the healthcare web application (can we stop calling this a website?) . Now there are many many instances where a Nosql is used along with traditional databases. And among the Nosql dbs, MarkLogic is way more mature than any other Nosql out there …MongoDB and the present crop included. In fact the federal government has been using MarkLogic for some time now and they would have had some idea about its strengths before using it at (lets give them the benefit of the doubt).

    Now, I have worked with MarkLogic and its is a pretty nifty piece of software. The problem is that it is pretty difficult to find people with expertise in Mark Logic. It is a non traditional database with strong roots in the XML native db community and that is not a standardized set of technologies that everyone plays with. And here is where the feds might have erred. The feds might have simply asked for parts of the solution to be developed in MarkLogic and CGI (and other companies involved in this debacle) might have simply agreed to it without bothering to know what it is all about.

  3. westamastaflash

    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.

  4. 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.

  5. Spook SEO

    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.

  6. 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…

  7. Robert Young

    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?

  8. Riley Rainey

    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.

      • What was the thesis?

        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.