Case Study 2 — The Fix That Was Being Undone: A Composite
Constructed. The practice, the vendor, and the figures are not real. The failure — a local configuration whose consequences were invisible because a third party had been silently correcting them for years — is the sharpest version of a pattern this book has now met eleven times.
Background
Section 27.5 contained a warning that reads like a hypothetical:
If your system consistently produces a malformed element and the clearinghouse consistently fixes it, you have a defect you will never find — until you change clearinghouses, or until a payer starts rejecting it directly, at which point it arrives as a sudden mass rejection of something that "has always worked."
This is the hypothetical happening.
The composite
Constructed.
A specialty practice, eight providers, a practice management system it has used for eleven years, and a clearinghouse relationship of similar vintage.
Years earlier — nobody can say exactly when — a payer required a piece of information in a place the practice's system did not populate by default. A capable person solved it the way capable people solve things: a configuration change. A field was set to populate from another field, which produced the value that payer wanted.
It worked. The claims paid. The person who made the change moved on.
What nobody knew
The configuration produced a value that was correct for that payer and malformed for the standard.
(Constructed.) Not wildly malformed — an identifier qualifier used in a way the implementation guide does not contemplate, populated on every claim the practice sent, to every payer.
And the clearinghouse normalized it.
Not as a favor to this practice specifically. Clearinghouses maintain large libraries of transformations — some payer-specific, some vendor-specific, some accumulated from years of watching what a particular submitter sends. This one was in the library. (Constructed.) It had been added by someone at the clearinghouse who noticed a pattern and made it work.
So for years:
THE PRACTICE'S SYSTEM produced a malformed element
↓
THE CLEARINGHOUSE quietly normalized it
↓
EVERY PAYER received a well-formed claim
↓
THE PRACTICE saw claims that paid
Every party behaved reasonably. The outcome was correct. And nobody held the whole picture.
What changed
The practice changed clearinghouses, for ordinary commercial reasons — price, service, a bundled feature. (Constructed.) A well-run project, planned over three months, with payer enrollments redone and test files exchanged.
The test files passed, because a test file is a small sample and the transformation library difference did not surface in it.
The first full production batch rejected at a rate nobody had ever seen.
The two weeks
(Constructed.)
The first response was to blame the new clearinghouse, which is the natural response and was wrong. The new clearinghouse's edits were correct; it was rejecting a genuinely malformed element.
The second response was to escalate to the practice management vendor, who reported — accurately — that the system was producing exactly what it was configured to produce.
Nobody was misinformed. Everyone was right. Chapter 25's Case Study 1 is the same shape, and this practice was two vocabularies away from resolving it for eleven days.
The resolution came from a biller (constructed) who asked the old clearinghouse for a copy of a transmitted 837 from a month earlier — §27.6's retrieval question — and compared it, element by element, with what the new one had rejected.
They were different files.
That comparison is the entire case study, and it was available to anyone who knew it was possible.
What it cost
(Constructed.)
Two weeks of substantially degraded submission, at eight providers' volume.
No claims were permanently lost — the rejections were caught immediately, the fix was a configuration change, and everything was resubmitted well inside every filing window. This is the good version of this story, and it is worth saying so.
The real cost was two weeks of an entire business office working a crisis, a delayed cash position that required attention, and a genuinely unpleasant fortnight for people who had done nothing wrong.
What it shows
First, a correct outcome is not evidence of a correct process. For years the practice's claims were well-formed when payers received them and malformed when the practice produced them. The organization had no way to know, because the only artifact it could see was the outcome.
Second, this is the eleventh time in this book that a configuration made an assertion nobody chose — and it is the sharpest, because the other ten were at least visible to someone who looked at a claim. This one was not visible on any claim anyone could see. The practice's copy showed one thing and the payer's showed another, and both were accurate records of different files.
Third, the person who made the original change did everything right by the standards of the moment. A payer needed a value; they configured the system to supply it; the claims paid. What was missing was not care. It was a record — of what was changed, why, and for which payer — and eleven years later nobody could reconstruct it.
Fourth, the test files passed. (Constructed.) This is worth dwelling on because it is the generalizable failure: a sample tests the common case, and the defect was in an element populated on every claim but only consequential against a rule the sample did not exercise. Chapter 21 §21.10's principle — you find patterns by looking at volume, not at examples.
And fifth, the resolution came from retrieving the actual transmitted file. Chapter 25's Case Study 1 said to learn how. This is the second consecutive part in which the answer was in a file the practice was entitled to and did not know it could ask for.
The lesson
Know what your system produces, not just what your payers receive. They are two different things and only one of them is yours.
Four carry-forwards:
Keep a log of configuration changes made to satisfy a payer. What, why, which payer, who, when. It does not need to be sophisticated — a shared document is enough — and its whole value is that it exists eleven years later when somebody asks why does our system do this?
Retrieve a transmitted 837 once, on a normal day, for no reason. §27.6. Look at it. You will not understand every element and you do not need to; you need to have seen the artifact and to know the retrieval path works.
Treat a clearinghouse migration as a change to your outbound claims, not a change of vendor. Run both in parallel if you can, and compare a real transmitted file from each for the same claim. Test files test the format; a production comparison tests the transformations.
And when a mass rejection arrives for something that has always worked, ask what changed on YOUR side — even when the obvious answer is that a vendor changed. Sometimes nothing changed on your side and that is exactly the problem: something stopped being fixed for you.
Discussion questions
-
Every party behaved reasonably and the outcome was wrong for years. Where should the responsibility sit, and what would a reasonable division of it look like in writing?
-
The test files passed. Design a migration test that would have caught this. What does it cost, and would you actually run it?
-
The original configuration change was made by a capable person solving a real problem. What single artifact would have made this composite impossible? Why do practices not maintain it?
-
The resolution required retrieving a transmitted 837 from the old clearinghouse. What would have happened if the relationship had already been terminated? What does that suggest about migration sequencing?
-
This is the eleventh configuration-made-an-assertion-nobody-chose finding in this book. Name three of the earlier ones and say what makes this one different.
-
Compare this with Chapter 25's Case Study 1, where a practice and a vendor could not translate between two vocabularies. What is the same? What does an eleven-year gap add that four months did not?