Contents
IBM and Curam agreed to pay $14.8 million over allegedly false Maryland health-exchange software readiness representations. The government’s allegations reached back to the purchase itself: what the software could already do, how far development had progressed, and whether it could work with the rest of the platform. If you worked on eligibility rules, tax credits or integration, you know the distance between a capability presented to a customer and the work still needed to deliver it.
The Department of Justice announced the settlement on June 14, 2019. It named International Business Machines Corporation and Cúram Software, whose technology formed part of Maryland’s Health Insurance Exchange website and IT platform. Cúram-IBM supplied software and services as a subcontractor to the state’s prime contractor.
This government software functionality case concerned the state’s purchase of a working system. Federal Department of Health and Human Services grants partially funded the Maryland Health Benefit Exchange contract. The federal money supported a state procurement, and the disputed representations came from a software supplier below the prime contractor.
According to the Justice Department, Cúram’s bid presentation illustrated software determining eligibility for health assistance, calculating applicable tax credits, handling changes in life events and integrating with another subcontractor’s health plan shopping software. Those functions put the procurement promise close to the people who would depend on the exchange: whether they qualified for coverage, what tax credit applied and what happened when their circumstances changed.
The government alleged that Cúram-IBM misrepresented the software’s existing ability to meet Maryland’s technical requirements, including calculating tax credits under the Patient Protection and Affordable Care Act. The allegations also concerned the development status of the Cúram for Health Care Reform software.
Development status and existing functionality are different parts of the same sales claim. For a developer or product specialist, the useful comparison is between the function shown to the buyer and the version of the software available at that time.
The government alleged that Cúram-IBM misrepresented its ability to handle life events, including the income changes illustrated in the bid presentation.
We would connect the representation about an income change to the requirement it addressed and the development or test record from that time. A general description of an eligibility product tells us less than the specific operation Maryland was shown it could perform.
Integration was itself part of the alleged misrepresentation. The Justice Department said Cúram’s presentation illustrated its software working with another subcontractor’s health plan shopping software, and the settlement covered allegations about integration with the other software needed for a functioning exchange website.
The buyer was purchasing a platform assembled from different suppliers’ work. We therefore examine what the component supplier said about that connection, alongside the component’s own capabilities. For an integration engineer, the important account may concern what happened where the systems met, and who understood that behavior when the presentation reached the state.
The Justice Department’s announcement dates IBM’s acquisition of Cúram Software Ltd. to December 19, 2011. It says that, on the same day, Maryland received a proposal that Cúram had helped draft and that included Cúram as a subcontractor for software and services.
The announcement describes Cúram’s January 5, 2012, presentation as part of the bid evaluation process, with IBM’s knowledge. Maryland, acting through the Maryland Health Benefit Exchange, awarded the development contract on February 22, 2012.
That sequence puts the alleged readiness claims before the award. The government’s account connects the proposal, the presentation and the purchase, giving an insider a much more specific starting point than the later website problems alone.
The subcontractor’s role also matters. According to the government’s account, Cúram helped write the proposal and presented its capabilities to the state. If you helped prepare those representations, you know a part of the purchase that a government invoice cannot explain.
The Justice Department said that, after repeated problems following the website’s October 2013 launch, Maryland terminated the contract and replaced the website and IT platform, including the Cúram software.
We expect a working exchange for public money. Maryland got a platform it had to replace. The government alleged that the sales pitch had misrepresented the development status, existing functions and integration before Maryland made the purchase.
The Justice Department, the U.S. Attorney’s Office for the District of Maryland, the Department of Health and Human Services Office of Inspector General, and the Maryland Attorney General’s Office coordinated the investigation and settlement.
Software readiness becomes a useful claim to examine when it names a function, a requirement and a point in development. In Maryland, the government’s allegations supplied those subjects: development status, existing eligibility-related functions and integration.
The 2024 Transparency International Anti-Corruption Helpdesk paper Transparency, Accountability, and Integrity of Public Procurement Systems says the purchasing procedure should reflect the complexity of the contract. That includes the scope of work, technical requirements and delivery schedule.
For us, those technical requirements make the insider’s explanation essential. Someone who understands the eligibility rules can explain what an income-change test actually tested. Someone responsible for integration can explain what a demonstration showed about the connection between systems. We connect that explanation to the particular promise the buyer received.
The purchasing records give those technical details their financial context. We examine the records behind the charge alongside the representation about the software, so the technical account stays connected to the government purchase.
Computer Sciences Corporation settled allegations that its electronic medical records system at Hanford was falsely represented as functional and able to meet contractual and Department of Energy requirements. The Justice Department announced that settlement on October 30, 2018. Former employees brought the whistleblower case.
The parallel is the promise about purchased software. Hanford’s case concerned an occupational-health records system. Maryland’s concerned the exchange’s eligibility functions and integration. In each, the allegation reached a claim about what the government was buying, making the technical employee’s knowledge directly relevant to the purchase.
For a software readiness case, useful proof connects what the company represented to the buyer, what the software could do at the time, and the purchase or payment that followed. Our whistleblower experts work through those connections with you.
Your role may give you a clear view of one part of this story. A proposal specialist may know how a capability was described. A developer may know its state of completion. An implementation employee may understand what the customer was shown. We bring those details together around the representations that mattered to the purchase.
A whistleblower case under the False Claims Act can pay 15% to 30% of what the government recovers. That is a reason to talk with experts who understand both the technical account and the procurement behind it.
If you know what the software could do when the buyer was told it was ready, tell our whistleblower experts about the capability that was promised. We build the case with you and bring in government procurement whistleblower lawyers who understand software representations, subcontractor roles and federal funding. You have a partner from the first technical conversation through the pursuit of a recovery.