Choosing a healthcare clearinghouse: run a trial, not an evaluation

Most clearinghouse selections run like software selections. You shortlist three vendors, you sit through three demos, you build a feature matrix, you check references, you negotiate, you sign. It is a perfectly respectable process and it answers almost none of the questions that will matter to you in eighteen months.

The reason is that you are not really buying software. You are buying an enrollment estate and a support relationship, and neither of those can be demonstrated.

What you are actually committing to

A clearinghouse sits between you and every payer you bill. To make that work, each payer relationship has to be established individually: EDI enrollment so claims can flow, ERA enrollment so remittances come back electronically, often EFT enrollment alongside it, and trading partner setup with identifiers that have to match on both sides. Some of this is API-driven and quick. A surprising amount of it is still a payer portal, a PDF, a wet signature, and a queue.

Multiply that by your payer mix, then by your provider or client count where enrollment is per-entity, and the estate you build in your first year is substantial. It is also the thing you lose if you move.

That is why the decision deserves more patience than it usually gets. You are choosing something you will be structurally reluctant to leave, which means you should be confident about it for reasons that survive contact with a bad month.

The three things a demo cannot show you

1. Enrollment throughput on your payer mix

Every clearinghouse handles the large national payers well. That is not where your pain will come from. Your pain comes from the regional plan, the Medicaid managed care organisation, the behavioural health carve-out, the plan that still wants a form faxed. What you want to know is how quickly enrollments actually clear for the payers in your book, and how often they come back needing rework. A vendor can tell you they support a payer. Supported and smooth are different words.

2. How support behaves when something is genuinely wrong

The test is not the response time in the service agreement. The test is what happens when an 835 has not arrived, the payer says it was sent, and someone needs to establish which of three organisations is holding it. That is an investigation across systems you do not control, and the only thing that makes it tractable is a support function that will look rather than deflect.

You cannot assess this from a reference call, because references are selected. You can assess it in a month of real traffic.

3. How legible their rejections are

Claims fail. That is normal and it is fine. What separates a good clearinghouse from a tolerable one is whether a rejection arrives in a form a biller can act on without a translation layer. Front-end rejections, 999 implementation acknowledgements, 277CA claim acknowledgements: these all exist in every clearinghouse, and the difference is whether the reporting turns them into a queue of actionable items or a spreadsheet of codes someone has to decode by hand every morning.

If the answer is the second one, you have just quietly hired a person. That cost never appears in the comparison.

What I would do instead

Run two or three clearinghouses in parallel. Give each one two to three months. Put several real payers live on each, and deliberately include the awkward ones rather than the easy ones. Then decide on observed behaviour.

This feels wasteful and it is not. The overlap costs you a few months of duplicated effort on a subset of payers. Getting it wrong costs you the migration, and the migration is measured in months of coordination across every payer and every client you have.

What to measure during the trial

• Days from enrollment submission to first clean claim, per payer, not averaged. The average hides the payer that took eleven weeks.
• Rework rate on enrollments — how often a submission comes back needing correction, and whether the clearinghouse caught it or the payer did.
• Time to first substantive response on a real missing-remittance ticket. Substantive, not acknowledged.
• Whether support can name a person. A named contact who has seen your account before is worth more than a faster queue.
• Rejection legibility — can a biller act on the report unaided, or does someone senior have to interpret it?
• Behaviour on an unsupported payer. Do they add it, route around it, or tell you it is your problem? You will need this eventually.

The part that is organisational, not technical

One more thing, and it is the one I care most about. The clearinghouse decision is usually owned by whoever runs the selection, and lived with by whoever works the exception queue. Those are rarely the same person, and the second person is not usually in the room.

If you take one thing from this: name, before you sign, who owns the clearinghouse relationship after go-live. Not who owns the contract. Who owns the outcome when enrollments stall and cash slows. If that person cannot be named, the decision has no owner, and an unowned vendor relationship degrades quietly for years before anyone calls it a problem.

Why I am writing this down

Because I chose on evaluation and reputation, which is the normal way to do it, and I would not do it that way again. The programme worked. Claims flowed, enrollments cleared, manual entry came down substantially. But the decision that shaped the next two years of everybody's working life was made in the least evidence-rich way of anything we did, and that still bothers me.

If you are at the point of shortlisting, the most useful question you can ask is not which clearinghouse is best. It is what you would have to see, with your own traffic, to be confident in eighteen months.