Trade Secrets

IDX v. Epic: A Trade Secret You Cannot Describe Is a Trade Secret You Cannot Protect

Judge Easterbrook held that a software company's forty-three-page, undifferentiated description of its medical-billing system failed to identify any trade secret with the specificity the law demands.

July 21, 2025
A software developer reviewing source code on multiple monitors
The court accepted that a real-time error-checking algorithm could be a secret — but IDX never separated it from features any user could see. Shutterstock
Educational content, not legal advice. This article explains general legal concepts. It does not create an attorney–client relationship. For your specific situation, consult a licensed attorney.

IDX Systems Corp. v. Epic Systems Corp., 285 F.3d 581 (7th Cir. 2002), Nos. 01-3083 and 01-3228, decided April 1, 2002, is the foundational federal authority for the proposition that identifying a trade secret is a threshold obligation, not a trial detail. Writing for a panel that included Judges Kenneth Ripple and Diane Wood, Judge Frank Easterbrook affirmed the dismissal of IDX’s trade-secret claim by the U.S. District Court for the Western District of Wisconsin. The reason was not that IDX’s information was public or valueless; it was that IDX never told the court — with the required precision — what its secrets actually were. The opinion has become a cornerstone of the “particularity” doctrine that now governs trade-secret pleading and discovery in courts across the country.

IDX made financial-management and billing software for medical practices. It accused Epic Systems, a competitor, along with the University of Wisconsin Medical Foundation and two individuals, of using IDX’s proprietary information to improve Epic’s competing product. The substantive accusation may have had merit. But the claim foundered at the most basic step in any trade-secret case: defining the secret.

At a glance

  • Case: IDX Systems Corp. v. Epic Systems Corp., 285 F.3d 581 (7th Cir.), Nos. 01-3083, 01-3228
  • Decision: April 1, 2002 (Easterbrook, J., for the panel; Ripple and Wood, JJ.)
  • Court below: W.D. Wis. (summary judgment / dismissal of the trade-secret claim)
  • Law applied: Wisconsin Uniform Trade Secrets Act
  • Core failure: IDX described its software in forty-three pages but never separated genuine secrets from generally known elements
  • Key line: “Unless the plaintiff engages in a serious effort to pin down the secrets a court cannot do its job.”
  • Doctrine: A trade-secret plaintiff must identify its secrets with specificity before it can prevail — and before the court can adjudicate the claim

Identification as a threshold requirement

The Wisconsin Uniform Trade Secrets Act, like every state’s version, protects information that derives independent economic value from not being generally known or readily ascertainable and that is the subject of reasonable secrecy efforts. Those elements cannot be evaluated in the abstract. A court cannot decide whether information is “generally known,” whether it carries secrecy-derived value, or whether the defendant misappropriated it rather than something public, unless the plaintiff first says what the information is. That is the structural insight of IDX: identification is logically prior to every other element.

IDX’s submission illustrated the failure mode the doctrine guards against. The company offered a forty-three-page description of the methods and processes underlying its software. But length is not specificity. The description, the court found, swept in everything — it described the software as a whole without separating the genuinely proprietary components from the ordinary features common to any billing package. Easterbrook’s formulation has been quoted ever since: “Unless the plaintiff engages in a serious effort to pin down the secrets a court cannot do its job.”

The practical consequence is that a plaintiff cannot define its trade secret as “our software” or “our system.” Software, like most complex products, is a layered assembly of public and proprietary parts: input and output formats, screen layouts, standard data structures, and — sometimes — genuinely novel algorithms buried underneath. Claiming the whole thing as a secret claims the public parts too, and a court will not parse the bundle on the plaintiff’s behalf.

Algorithms versus what the user can see

The opinion is careful, and that care is what makes it durable. Easterbrook did not say IDX had nothing worth protecting. He acknowledged that some elements — an algorithm performing real-time error checking, for example — could be genuine trade secrets. The problem was that IDX never isolated such an algorithm and never showed that the defendants had obtained it. Instead, IDX’s allegations centered on features that ordinary users could observe in normal operation: the appearance of data-entry screens and similar surface characteristics.

That distinction maps directly onto the “readily ascertainable” element. Information a user can see simply by operating licensed software, without reverse engineering, is generally not secret as to that user. The look of a data-entry screen is observable; the underlying code that an algorithm runs is not. IDX pointed at the observable layer while the protectable material, if any, lived in the layer it never identified. The claim therefore failed not because the algorithm was unprotectable, but because IDX litigated the wrong thing and never pinned down the right thing.

For software companies, the lesson is concrete. The protectable core of a software product is rarely its visible interface; it is the architecture, data models, optimizations, and algorithms that the interface conceals. A trade-secret claim that rests on what the defendant could see on screen is, in most cases, a claim about non-secret information.

Why the rule benefits everyone — including plaintiffs

Particularity is sometimes framed as a defense-friendly trap, but IDX explains why it is structurally necessary. Without a specific identification, discovery becomes a fishing expedition in which the plaintiff inspects the defendant’s product and then defines its “secret” to match whatever it finds — the very vice the doctrine prevents. Specific identification also protects the defendant’s right to show independent development or public availability, which is impossible to litigate against a moving target. And it disciplines the plaintiff’s own thinking: the exercise of pinning down the secret often reveals which components are genuinely protectable and which are not.

The decision has been widely followed and is routinely cited for the now-standard requirement that a trade-secret plaintiff describe its secrets with enough particularity to separate them from matters of general knowledge — often early in the case, before broad discovery. Many courts and several jurisdictions now formalize this through early-identification orders or statutes modeled on the same logic.

Open questions

IDX establishes that vague, all-encompassing descriptions are insufficient, but it does not fix the precise level of detail required, and courts have since divided on how granular identification must be and at what stage. How early in litigation must a plaintiff disclose its secrets — at the pleading stage, before discovery, or only before trial? The opinion also does not resolve the tension between requiring specificity and protecting the secret itself: a plaintiff understandably resists spelling out its secrets in a public filing, and the mechanisms for reconciling disclosure with confidentiality (protective orders, in camera submissions) vary widely. Finally, IDX leaves open how the rule applies to combination trade secrets, where the protectable thing is the arrangement of otherwise public elements rather than any single component.

Implications

  • Identify before you litigate. Define the specific information claimed as secret before filing; “our software” or “our system” is not an identification.
  • Separate the secret from the surface. Distinguish protectable architecture, data models, and algorithms from observable screens, formats, and standard features.
  • Length is not specificity. A long, undifferentiated description can fail as completely as a vague one if it does not isolate the secret from the generally known.
  • Match the secret to the proof. Allege that the defendant obtained the identified secret — not merely something a user could see in normal operation.
  • Expect early-identification practice. Many courts now require particularized disclosure early in the case; prepare the identification before discovery, not after.

Frequently asked questions

Did IDX lose because its software wasn’t proprietary? No. The court accepted that some elements, such as a real-time error-checking algorithm, could be genuine trade secrets. IDX lost because it never identified its secrets with the required specificity and pointed instead at features users could observe.

What does it mean to identify a trade secret “with particularity”? It means describing the specific information claimed as secret in enough detail to separate it from publicly known or readily ascertainable material — so the court can test secrecy, value, and misappropriation against a defined target rather than a vague reference to a whole product.

Why can’t the plaintiff just identify the secret later, at trial? Because every other element depends on knowing what the secret is. Without an early, specific identification, discovery becomes a fishing expedition and the defendant cannot fairly litigate independent development or public availability.

Authorities and sources