Evaluate building or buying medical coding AI using a framework for integration, validation, ongoing maintenance and total cost.
Every health system with a data science team eventually asks whether it should build its own coding engine. The question is fair. You have charts, you have credentialed coders, and you have engineers who have shipped harder things than a classifier. The build vs buy medical coding AI decision usually goes wrong for a different reason: teams scope it as a modeling problem when it is a maintenance problem. A system that assigns codes correctly in March is wrong on April 1, wrong again on October 1, and wrong in a new way every quarter CMS refreshes its edit files.
This article covers what a build actually contains, what it costs to keep alive, and six tests that settle the question.
What you are actually building
Whichever design you pick, the engine underneath is six layers. The model is one of them:
1. Integration: HL7 v2 and FHIR interfaces, document retrieval, scanned and faxed reports, transcription output, and a write-back path into the abstracting system and the claim scrubber. In any large Epic or Oracle Health estate this layer alone is a multi-quarter project before a single code is assigned.
2. Extraction. Clinical language processing that holds up against negation, laterality, temporality, family history, and hedged documentation. "No evidence of pulmonary embolism" and "pulmonary embolism" differ by three words and, on an inpatient stay, by a Medicare Severity Diagnosis Related Group (MS-DRG).
3. Assignment with version control: Every code set is versioned against date of service or date of discharge. A March discharge coded in May must be assigned against the March version of ICD-10-CM, the March MS-DRG grouper, and the March NCCI file. Version-aware assignment is a data engineering requirement, not a model capability, and it is where in-house builds most often produce silent errors.
4. Edits and grouping: Medicare Code Editor, Integrated Outpatient Code Editor, National Correct Coding Initiative (NCCI) procedure-to-procedure and Medically Unlikely Edit files, MS-DRG assignment, Ambulatory Payment Classification assignment, and whatever methodology your state Medicaid program pays on.
5. Coder review and audit trail: Worklists, routing logic, confidence thresholds, and a durable record of what the system suggested, what a credentialed coder accepted or overrode, and on what documentation. Coding output without that record is not defensible in an audit, which makes the trail a compliance component rather than a reporting feature.
6. Measurement: A held-out, dual-coded reference set and an evaluation pipeline that reports agreement by code set, service line, and code family. Without it you cannot state whether the system works, which means you cannot govern it.
Your engineers want to build layer two. It is the smallest share of the work and the only layer with a published research literature behind it.
The licensing layer most build plans miss
Three of the four code sets a US hospital needs are free. One is not.
ICD-10-CM and ICD-10-PCS are published by CMS and the National Center for Health Statistics and carry no licence fee. HCPCS Level II is published by CMS on the same terms. The MS-DRG grouper logic and Definitions Manual are published by CMS, so MS-DRG assignment is buildable without a commercial agreement.
CPT is different. The code set is copyrighted by the American Medical Association, and the AMA states that a licence and royalty are required for uses including developing, testing, maintaining and servicing products that use or rely on CPT content. An internal-use licence and a distributor licence are separate products with separate terms. Building in-house does not remove that line item, it moves it from your vendor's contract to yours, and it attaches reporting obligations to your own engineering roadmap.
All Patient Refined Diagnosis Related Groups (APR-DRG) is also proprietary. The methodology is owned and licensed by Solventum, formerly 3M Health Information Systems, and the APR-DRG Definitions Manual is available only to licensees. If any part of your payer mix pays on APR-DRG, and for most Medicaid and commercial contracts some part does, you are licensing a grouper whichever path you take.
A build reduces the number of vendors in the stack. It does not take it to zero, and the two licences it cannot avoid are the two that sit closest to payment. Grouper coverage is an inpatient question in practice rather than a category-level one, and it is handled as part of inpatient DRG coding.
If the decision is already leaning one way, the fastest way to test it is against a working system rather than a spreadsheet.
The maintenance calendar you inherit
This is the part that decides most build cases, and it rarely appears in the business case.
| Recurring date | What changes | 2026 cycle, actual | Who owns it if you build |
|---|---|---|---|
| January 1 | CPT annual revision; NCCI quarterly files; HCPCS quarterly update | NCCI version 32.0 files effective January 1, 2026 | Your team, every year |
| April 1 | ICD-10-CM and ICD-10-PCS mid-year update; MS-DRG grouper release; NCCI quarterly files | 80 new ICD-10-PCS codes, zero new ICD-10-CM codes, MS-DRG grouper V43.1, NCCI version 32.1 | Your team, every year |
| July 1 | NCCI quarterly files; HCPCS quarterly update | NCCI PTP version 32.2 effective July 1, 2026 | Your team, every year |
| August | IPPS final rule published for the coming federal fiscal year | Governs October 1 changes | Your team must read and implement it |
| October 1 | New fiscal year ICD-10-CM and ICD-10-PCS; new MS-DRG version; NCCI quarterly files | NCCI PTP version 32.3 effective October 1, 2026 | Your team, every year |
| November | OPPS and Physician Fee Schedule final rules | Governs January 1 changes | Your team must read and implement it |
| Continuous | MAC local coverage determinations, payer policy bulletins, Coding Clinic advice | No fixed cycle | Your team, indefinitely |
The April 1, 2026 cycle is the clearest illustration of why a code-list refresh is not maintenance. CMS and NCHS added no new ICD-10-CM diagnosis codes at all that cycle. What changed was instructional notes, including Excludes1 notes that became Excludes2 notes, which means code pairs that could never be reported together became reportable together when both conditions are documented. A pipeline that ingested a fresh code file would have detected nothing. Any rule that had encoded the old exclusion as a hard constraint kept enforcing a restriction CMS had removed, and kept doing it silently.
The same cycle brought 80 new ICD-10-PCS codes and MS-DRG grouper version 43.1. On the outpatient side, NCCI version 32.1 added more than 3,750 procedure-to-procedure pairs and deleted more than 4,800, alongside 121 new Medically Unlikely Edits. Those files are also where pre-bill edits fail first, which is why keeping them current sits as much inside denial prevention as inside coding.
Six dated events, plus two final rules to read, plus continuous local coverage changes, every twelve months, permanently. Buying puts that calendar on someone else's roadmap with a contractual service level attached. Building means your team owns it in perpetuity, including the quarters where the work is tedious and the person who understands the grouper logic has left.
Your historical charts are not ground truth
The intuitive training plan is to use your own coded history. You have years of it, it is already labelled, and it reflects how your organisation codes.
That last part is the problem. Coded history is coder output, not ground truth. It carries your historical error rate, your query patterns, your habits at complication and comorbidity boundaries, and every default your previous encoder suggested. A model trained on it learns to agree with your past coders, then reports high agreement and presents it as accuracy. You have built a very expensive mirror.
A defensible reference set means blinded dual coding by credentialed coders, third-party adjudication of disagreements, stratification by service line and payer, and a refresh after each code set cycle so the benchmark does not drift out of date. That is recurring work requiring CCS and CPC time, which is the exact resource constraint that started the conversation.
Six tests that settle build vs buy
Apply all six. Build is viable only if it clears every one, because each failure is independently fatal rather than a point to trade off.
| Test | The question | Build is viable only if |
|---|---|---|
| Volume | Does annual chart volume amortise the build and the permanent maintenance team? | You have enough volume that per-chart internal cost beats vendor pricing after the calendar is staffed |
| Scope | Can you bound the first build to one high-volume, low-variance service line? | Yes, and the business case survives without the harder specialties |
| Labels | Can you fund a blinded, dual-coded reference set and refresh it on every cycle? | Credentialed coder time is budgeted for it, not borrowed |
| Maintenance | Can you staff the code set calendar indefinitely, not just through go-live? | Named owners exist for each recurring date, with a succession plan |
| Licensing | Can you clear CPT, and APR-DRG where your payer mix requires it? | Both agreements are executed, with royalty reporting built into your process |
| Defensibility | Can you produce validation evidence and an audit trail a RAC or OIG reviewer accepts? | Change control, version pinning, and override logging exist before first production use |
Most systems fail Maintenance or Labels, and they fail them after the build is finished, which is the expensive way to find out.
The choice is not binary
Framing this as build or buy hides the two positions that work most often.
Full build: Every layer in-house. Defensible for the largest academic systems and provider-payer organisations with existing clinical informatics research capacity and chart volume in the millions.
Narrow build: One bounded, high-volume, low-variance service line built in-house, everything else bought. The honest version of a build for most systems, and the one where a pilot can fail cheaply.
Buy and extend: A vendor engine underneath, with your own configuration layer on top: internal edit rules, query templates, worklist routing, documentation gap reporting. This is usually where the durable in-house asset actually sits, because it encodes institutional knowledge a vendor cannot supply and does not need to be revalidated every April.
Buy. The engine, the calendar, and the validation burden all sit with the vendor under contract.
The tier you automate at is a separate decision from who builds it, and it changes the risk profile more than the build question does. Cost structure differs across all four positions, and how the pricing models compare is the next question after this one.
If you are leaning buy, ask these six questions
Each one maps to a test above, and each has a verifiable answer.
- Who owns the code set calendar, and what is the contractual deadline for implementing an October 1 change?
- Show the validation record for the April 1, 2026 update. Specifically, how were the Excludes1 to Excludes2 changes handled and retested?
- Which CPT licence do you hold, and does our use fall inside it?
- Which grouper methodologies are covered, and what happens on a payer that pays on APR-DRG?
- What does the audit trail export look like when a RAC reviewer asks why a code was assigned?
- On exit, what happens to our configuration, our reference set, and our coded history?
A vendor who answers question two with a date rather than a description has not done the work. That question is the fastest way to separate a maintained system from a demo.
Build vs buy medical coding AI is decided by what happens in the twelve months after go-live, not the twelve weeks before it. If your team can clear all six tests, build. If it cannot clear one of them, the honest path is to buy the engine and spend your engineering capacity on the configuration layer that only you can build.
This article is educational and does not constitute a coding determination for any specific encounter. Code assignment depends on the documentation in the individual record and on payer policy in effect on the date of service.
Frequently asked questions
Can we build coding AI on top of a general-purpose large language model?
Partly. A general model can carry layer two, extraction, with prompting and evaluation work. It does not give you version-aware assignment, edit and grouper logic, an audit trail, or a reference set, and it introduces a question about protected health information leaving your environment that your privacy office will want answered in writing before a pilot, including a business associate agreement with every subprocessor in the path.
Does building in-house avoid CPT licensing costs?
No. The AMA requires a licence and royalty for uses including developing, testing, maintaining and servicing products that rely on CPT content. Building moves that obligation from your vendor's contract into yours, along with its reporting requirements.
How long before an in-house build codes its first production chart?
That depends on integration and governance rather than modelling, so treat any estimate that starts with model development as incomplete.
Does building get cheaper at higher chart volume?
The build cost amortises, but the maintenance cost does not scale down and the specialty mix usually widens with volume, which raises the validation burden. Volume improves the case for a narrow build in one service line more than it improves the case for a full build.
Sources referenced in this article: CMS ICD-10 code files and April 1, 2026 update package; CMS NCCI PTP and MUE quarterly files, versions 32.0 to 32.3; AMA CPT licensing requirements; Solventum APR-DRG licensing and Definitions Manual availability.
