How Legal and Claims Teams Decide Between Building Medical Record AI and Buying It

Most teams do not decide to build medical record AI. They drift into it. Someone wires an API to a model, it works on a clean PDF, and eighteen months later there is a system nobody owns and a backlog nobody can clear. This guide covers what building actually requires, what buying actually costs, and the criteria buyers use when they shortlist vendors.

Why the Build vs Buy Question Comes Up Later Than It Should

The question rarely arrives as a strategy exercise. It arrives as a capacity problem. A firm or claims unit hits a volume it cannot staff through, and someone asks whether software can absorb it.

By then the decision is already constrained. You are choosing under deadline pressure, which is the worst condition for a build.

The Trigger Is Usually Volume

Nobody builds a document pipeline for fifty cases a year. The conversation starts somewhere around the point where record review stops being a task and becomes a queue.

That threshold differs by team. For plaintiff firms it tends to be case volume. For carriers it tends to be surge, where a normal month is manageable and a bad one is not.

What Teams Underestimate

The model is not the hard part, and it has not been for a while. What consumes the budget is everything wrapped around it.

Document boundary detection on a 900-page scanned production. Deduplication across overlapping records from three providers. Page-level citations that survive a deposition.

Each of those is a project. Together they are a product.

There is a second thing teams miss, which is that the work never reaches a finished state. Providers change their export formats. Models get deprecated. A new document type appears and the classifier has never seen it.

A bought system absorbs that churn on someone else’s roadmap. A built one absorbs it on yours, permanently, with the same engineers who were supposed to move on to the next thing.

What Building Actually Requires

A working prototype is a weekend. A system a paralegal will trust is not.

The Model Is the Easy Part

Calling a model and getting fluent output is close to free now. Getting output you can defend is where the work lives.

A summary that reads well and cites nothing is worse than no summary, because someone will rely on it.

Extraction Accuracy on Real Documents

Vendors quote 92 to 97 percent accuracy on clean digital records. Your files are not clean digital records.

They are faxed operative notes, handwritten intake forms, and EHR printouts scanned at an angle. Accuracy on that material is the only number that matters, and it is well below the marketing figure for every system, built or bought.

The gap between those two numbers is the entire engineering problem. Anyone who has not measured it on their own documents does not yet know what they are signing up for.

The Human QA Layer Nobody Budgets For

Every serious medical record system has people in it. The question is whose people.

If you build, you staff reviewers, write the review protocol, and own the error rate. That is a standing operational cost, not a one-time build cost. Teams routinely model the engineering and forget this line entirely.

The arithmetic is unforgiving at scale. A 3 percent error rate means roughly one summary in thirty carries a material miss. On high-exposure files that is not an acceptable rate, and closing it takes people rather than a better prompt.

This is also the clearest question to put to a vendor. Ask whether a human reviews output before it reaches you, and if the answer is no, understand that you have not removed the QA cost. You have relocated it to your own team. Our guide to AI medical record review for law firms covers where that review step belongs in a working process.

What Buying Actually Costs

Buying is not cheap, and the pitch that it is should make you suspicious.

Per-Page and Per-Case Pricing

Token costs do not go to zero the way infrastructure costs do. Every page processed carries a real marginal cost, whether you pay it directly or inside a vendor’s rate.

That single fact compresses the gap between building and buying more than most build cases assume.

The build case usually models inference cost against vendor list price and stops there. It should model inference plus engineering salary plus reviewer salary plus the maintenance tail, against the vendor rate. Done honestly, the crossover point sits at a much higher volume than teams expect.

Cost	Build in-house	Buy from a vendor
Per-page inference	Paid directly, at your own negotiated rate	Bundled into the rate, with vendor margin
Engineering	Salaried, ongoing, never finished	None
Human QA	You staff and manage it	Included, or explicitly not
Compliance	Yours entirely	Shared, but you still own the BAA
Time to first output	Months	Days

The Switching Cost Question

The honest argument against buying is dependency. If your workflow assumes one vendor’s output format, leaving is expensive.

You reduce that by insisting on exportable, source-linked output from the start. A chronology that maps every entry to a page and Bates number is portable. A proprietary summary blob is not.

Build vs Buy, Factor by Factor

Factor	Build	Buy
Speed to first usable output	Months	Days
Control over the pipeline	Total	Bounded by the roadmap
Required expertise	ML and document engineering hires	None
Maintenance	Permanent	Vendor’s problem
Accuracy on messy scans	However good you make it	However good they made it
Surge capacity	Limited by your infrastructure	Usually elastic

Speed to First Output

This is the factor that decides most cases, and it is rarely the one teams argue about. A build that ships in nine months costs nine months of the problem you were trying to solve.

Control and Customization

Control is real and worth something. It is worth less than teams expect, because most customization requests turn out to be workflow preferences rather than model behavior.

Compliance Burden

Building does not reduce your compliance load. It concentrates it. You own the BAA, the encryption posture, the audit trail, and the breach response. Under 45 CFR 164.524 and the wider HIPAA framework, that responsibility does not transfer just because the code is yours.

How Buyers Actually Shortlist Vendors

Search behavior here is specific. Buyers are not asking which tool is best. They are asking which vendors clear their gates, which is a different question with a different answer.

Gate	What to ask	Why it decides the shortlist
Security	SOC 2, BAA, data residency	Procurement blocks without it, regardless of quality
Accuracy evidence	Results on your documents	Vendor benchmarks use clean files
Source linking	Page and Bates citations	Unlinked output is not defensible
QA model	Human review before delivery, or not	Determines your internal review burden
Surge capacity	Throughput ceiling and notice period	A vendor that caps out in a bad month is not a vendor

Security and Compliance Gates

This is a pass or fail filter applied before anyone looks at output quality. No BAA means no pilot. No SOC 2 means procurement stops the conversation at most carriers.

Publish your requirements before the demos start. It saves everyone a month.

Scope is the thing teams forget to check. A SOC 2 report covers named systems over a named period, not the whole company forever. Ask which systems the report covers and how recent it is, because a report that excludes the product you are buying tells you nothing.

Ask where data is stored, who can access it, and how long it is retained after a matter closes. InQuery publishes its posture on the security page precisely because these questions arrive in every procurement cycle.

Accuracy Evidence, Not Accuracy Claims

Ask every vendor to run your files. Not their sample set, yours. Pick a case you already know well, including one you found difficult.

Then compare what comes back against what you know is in the record. That single exercise separates vendors faster than any feature matrix.

Source Linking and Defensibility

An entry that does not cite a page cannot be checked, and anything that cannot be checked will eventually be wrong in front of someone who matters. InQuery builds source-linked chronologies where every line traces to its page and Bates number, which is the standard worth holding all vendors to.

Our platform evaluation guide covers the full criteria list, and how to evaluate summarization tools walks the scoring in more depth.

Throughput and Surge Capacity

Averages hide the tail. Ask what happens in your worst month, not your typical one, and ask how much notice a volume increase requires.

Run a Pilot Before You Decide

A pilot answers in three weeks what a strategy deck argues about for three months.

Pick Files You Already Know

Use closed cases where you know the answer. You are testing whether the system finds what you already found, which is the only test with a scoring key.

Include at least one file that gave your team trouble. Clean files tell you nothing.

Measure Against Your Current Process

Run the vendor in parallel with your existing workflow on the same cases. Compare turnaround, what each surfaced, and how much review the output needed before anyone would send it.

Track the review time specifically. A summary that takes two hours to verify has not saved you two hours.

Set the success criteria before the pilot starts, in writing. Otherwise the evaluation collapses into whose output reads better, which is the least predictive thing you can measure.

Three numbers are usually enough. Turnaround from upload to usable output, review minutes per case before anyone would send it, and misses against the file you already knew. Adoption tends to go better in stages than as a firm-wide switch, and a scoped pilot is the first stage.

When Building Is the Right Call

Building is sometimes correct. It is correct less often than it is attempted.

Genuine Product Differentiation

If the output is your product rather than an input to your product, build. A company selling record review as its core offering is in a different position from a firm consuming it.

Volume That Amortizes the Investment

Sustained, predictable, high volume changes the arithmetic. If you are processing enough pages that per-page vendor margin exceeds a team’s fully loaded cost, the build case becomes real.

Run that number honestly, including QA staffing and the maintenance that never ends.

The Hybrid Most Teams Land On

The common resolution is neither pure option. Teams buy the document pipeline and build the workflow around it.

You get retrieval, sorting, indexing and chronology construction from a vendor, then own the case management, review queue, and client-facing product yourself. That keeps your engineering pointed at the part clients actually see, and puts the document problem with people whose whole job it is.

Where that lands for a carrier differs from a plaintiff firm. Carrier-side buying criteria weight reserve accuracy and defensibility, while firms weight demand quality and speed. Cost structures differ too, which our breakdown of summary software costs covers.

Vendors worth putting on a shortlist include Supio, Wisedocs, DigitalOwl, Tavrn, Filevine and Legalyze, alongside InQuery. Our comparison of software versus services covers the outsourcing option, which is a third path teams often skip.

Adoption across the profession is running ahead of most firms’ internal planning. CasePeer’s survey work puts generative AI use among personal injury lawyers above the legal average. The practical consequence is that the build timeline competes against a moving baseline, not a static one.

Frequently Asked Questions

Is it cheaper to build medical record AI in-house?

Rarely, once you count everything. Per-page inference costs persist either way, and building adds salaried engineering plus a human QA function most models leave out. The build case gets strong at sustained high volume or when the output is your product rather than an input.

How long does building a usable system take?

A prototype takes days. Something a paralegal will rely on takes months. The distance between those is document boundary detection, deduplication, page-level citations, and accuracy on scanned and handwritten material.

What should I ask vendors first?

Ask for a BAA and SOC 2 before anything else. Procurement will block without them regardless of output quality. Then ask them to run your own difficult files, not their sample set. Our best summary software comparison lists the rest of the criteria.

Does buying lock me into one vendor?

Only if you let the output shape your workflow. Insist on exportable, source-linked results that map to page and Bates numbers. Portable output keeps switching costs low.

Can we start with a vendor and build later?

That is the most common sensible path. A vendor pilot produces the usage data and gap list that a credible build case requires, and it does so while the backlog is being worked rather than while it grows. If you want to test that on a real file, start here.