Contents
Contents
EHR gag clauses are contract terms that restrict what users can say about electronic health records software, including its usability and safety problems. The federal Communications Condition protects specified communications about certified developers’ technology, expressly including screenshots and video. For a clinician who sees an order disappear, a technician who can reproduce the failure, or a customer told to keep quiet about the product, that protection matters. The screen is where the problem becomes visible. The contract can determine whether anyone else gets to see it.
An EHR gag clause restricts discussion of the software through confidentiality, nondisclosure, intellectual-property or non-disparagement language. The restriction may sit inside an ordinary health care customer agreement. A clause need not call itself a gag clause to limit what a hospital or practice says about a product it bought.
The Office of the National Coordinator for Health Information Technology described these practices in its rulemaking. It identified contracts that restricted voluntary discussion of problems, reporting of usability and safety concerns, or statements that might reflect negatively on the developer. The concern reached the information another buyer or clinician would need to assess the product.
The Communications Condition of Certification addresses those developer restrictions. It protects discussion of how the software works, including visual evidence of its problems.
Contract restrictions can keep users from sharing the interface and workflow that expose a safety problem. That was a central finding of the Institute of Medicine’s Health IT and Patient Safety: Building Safer Systems for Better Care.
The report’s summary described contractual barriers to sharing adverse events, screenshots of risky interfaces and descriptions of unsafe processes. It also identified contracts that shifted responsibility for software errors away from vendors. The committee concluded that restrictions on transparency contributed to gaps in knowledge about patient safety.
It put the relationship between the product and the work plainly:
Safety is an emergent property of a larger system that takes into account not just the software but also how it is used by clinicians.
That is why the clinician’s account belongs beside the product specification. A screen, a sequence of actions and the way a hospital configured the software can explain a failure that a description of the product’s features misses.
The 2019 Kaiser Health News and Fortune investigation, Death by a Thousand Clicks: Where Electronic Health Records Went Wrong, showed the problem before the Communications Condition’s contract-notice requirements began. It reported that gag clauses discouraged buyers from discussing safety problems and failed installations. It also described confidential settlements that kept the facts behind medical-negligence allegations out of public view.
One pediatrician told the reporters that colleagues could not understand why parts of their notes disappeared. They eventually traced the problem to curly brackets: entering them deleted the text between them. The account makes the value of a specific workflow obvious. A complaint about missing documentation becomes much more useful when someone can explain which keystrokes made it vanish.
We see the absurdity in requiring clinicians to work through software problems while contract language keeps their experience from reaching others using the technology. The people closest to the failure hold precisely the information the next user needs.
The Communications Condition protects discussion of usability, interoperability, security, relevant user experience, the developer’s business practices related to exchanging electronic health information, and how a user has used the technology.
Safety concerns can arise within those subjects. The report of a missing order describes a user’s experience and the way the system was used. Discussion of an interface that makes a medication choice confusing concerns usability. The rule reaches the work performed with the product, as well as the product itself.
Even proprietary or confidential information can fall within the rule’s protection, depending on the subject, purpose and recipient of the communication. We work through the clause and the information with you, bringing in EHR whistleblower lawyers for the disclosure questions specific to your role.
The rule defines communication to include screenshots and video, regardless of the form or medium used. A developer’s restriction on showing the interface falls within the same framework as a restriction on describing it in words.
For someone who works in the system, the screenshot’s value is its specificity. Which field was visible? Which option did the clinician choose? What appeared after the order changed? We connect that account to the software and the workflow. The 2019 investigation described how local customization made systems difficult to compare and made the source of mistakes harder to identify. The configuration belongs in the story.
The federal rule had to name screenshots. Even showing the problem had become a contract issue.
The Communications Condition requires developers to address conflicting terms already in their contracts. Since 2021, developers have had to notify customers and other contracting parties each year that they will not enforce conflicting clauses, until the required contract changes are complete.
For older agreements covered by the rule, developers must remove or void conflicting clauses at renewal or when the contract is changed for another reason. The rule also prohibits establishing, renewing or enforcing an agreement that conflicts with the Communications Condition.
For a hospital purchasing or compliance team, the old clause, the notices and the later renewal tell the story together.
The Communications Condition binds the certified health IT developer. A vendor’s customer contract and an employer’s instruction to staff are different restrictions, even when they concern the same screen.
We work through the source of the restriction with you and the whistleblower counsel we bring to your case.
We work through HIPAA and disclosure questions with you and EHR whistleblower counsel, based on your role and the information involved. Patient information and proprietary records call for that specific review. The useful first conversation is about what you observed and the restriction you were given, with expert help on how the underlying material can support a case.
The government’s allegations about CareCloud’s Champions Program show how a restriction on negative information can also become part of a sales arrangement. In April 2021, the company agreed to pay $3.8 million to resolve allegations that it paid unlawful kickbacks to generate sales of its EHR products.
The government alleged that CareCloud offered existing customers credits, cash bonuses and percentage success payments to recommend its products. Those customers allegedly signed agreements prohibiting them from giving prospective customers negative information about the EHR. The prospective buyers were allegedly told about neither the compensation nor the restriction on what the references could say.
The settlement agreement’s account of the alleged conduct puts the payment and the silence together. The government alleged that the referral payments violated the Anti-Kickback Statute and made federal incentive claims false under the False Claims Act. The programs included Medicare and Medicaid EHR incentives and the Merit-Based Incentive Payment System.
A buyer seeking another customer’s experience allegedly received a recommendation with both the payment and the contractual editing hidden.
We call that a remarkable way to sell medical software: pay for the praise, contract away the criticism, and leave the buyer unaware of either arrangement.
The Department of Health and Human Services’ Office of Inspector General investigated, and the government joined a case brought by a whistleblower.
Useful EHR fraud evidence connects what the system did, what the vendor represented and the government payment involved. Customer-site knowledge can make that connection. The whistleblower behind the eClinicalWorks case was a software technician at a municipal health agency that used the product.
The government alleged that eClinicalWorks concealed software deficiencies to obtain certification and caused false claims for federal incentive payments. Its complaint described a particularly revealing failure: customized prescriptions could lose the drug codes needed for interaction checks. The complaint quoted the company’s description:
any change to a custom strength, custom formulation, etc. will strip the NDC code from the medication and cause interaction checking not to fire.
That passage connects an ordinary clinical action to a missing safety check. The government alleged that other problems could reappear across software versions or remain unresolved for other customers. A technician who understands the version and the failure, or a clinician who knows the sequence that produces it, brings knowledge that the screen alone cannot supply.
We examine those connections with you: the user experience, the company’s knowledge, its representations and the payment. A whistleblower case under the False Claims Act can pay 15% to 30% of what the government recovers.
If you work with an EHR and know the failure behind a restricted screenshot, or the payment behind a carefully managed customer reference, speak with our whistleblower experts about what you have seen. We build the case with you around the software, the decisions and the money, and bring in EHR fraud whistleblower lawyers who understand certification and referral arrangements. You bring the inside view; we bring the expertise and stay beside you through the case.