Autonomous Medical Coding: HL7-Driven ICD-10 & CPT Prediction Without a Custom EHR API
Nirmitee.io
Author
Executive Summary
A US-based revenue-cycle technology company set out to remove the human bottleneck from medical coding — an engine that assigns ICD-10 and CPT codes the moment a clinical encounter closes, then hands the result straight to billing. The hard part was never the model. It was getting clean, complete clinical data out of whatever EHR a provider happens to run, without building a custom API for every vendor.
We built an event-driven, autonomous coding pipeline that consumes the HL7 and FHIR integration messages an EHR already produces, normalizes them, and feeds a clinical NLP engine that predicts billing codes with a confidence score on every prediction. Because it reads standard HL7 rather than a proprietary API, the same integration works with virtually any HL7-capable EHR — Epic, Cerner, or athenahealth.
The Challenge: Coding Is Still a Manual, Retrospective Bottleneck
Medical coding is largely a manual, after-the-fact process. Once an encounter is complete, a coder reviews the clinical notes, lab results, diagnoses, and procedures, then assigns the ICD-10 and CPT codes that drive the claim. That sequence introduces real operational cost:
- Coding backlogs that delay claim submission and push back revenue realization.
- Coding inaccuracies that surface later as claim denials or compliance risk.
- Dependency on scarce, experienced coders for high-volume, routine encounters.
- No real-time visibility into coding status across encounters.
- Manual re-entry of data that already exists in the EHR clinical record.
Why This Integration Is Different
Most EHR integrations pull data through proprietary APIs or FHIR endpoints — which means managing authentication, tenant IDs, and rate limits separately for every vendor, and waiting on each provider's IT team to expose the data. For a product that needs to work across many facilities and EHR vendors, per-vendor API plumbing does not scale.
This platform takes a more universal route: it consumes the HL7 messages the EHR already sends on encounter closure. The pattern we see across coding and revenue-cycle products is the same — the data the AI needs already exists in the messages the EHR emits. The integration problem is plumbing, not access.
Solution: An Event-Driven, Autonomous Coding Engine
We designed the engine as a passive, event-driven listener. Instead of querying or polling the EHR, it waits for the EHR to push standard HL7 messages — the message types every HL7-capable system already generates. Nothing about the provider's clinical workflow changes. Mirth Connect sits in the middle as the integration engine, and our healthcare AI solutions engine does the coding.
The end-to-end flow
- Encounter closure. The provider documents and signs the visit; the EHR closes the encounter and triggers the downstream workflow.
- HL7 messages published. The EHR transmits one or more HL7 messages carrying demographics, observations, chart notes, lab results, diagnoses, procedures, and orders.
- Mirth receives and parses. The integration channel listens on an LLP/MLLP port, identifies the message type (ADT, ORU, MDM, ORM), and parses each segment.
- Aggregation by encounter. Because a single encounter can produce several messages in sequence, Mirth aggregates them by Encounter Number, Visit Number, MRN, and Account Number — so the engine receives one complete clinical picture, not fragments.
- Normalization to JSON. Aggregated HL7 is transformed into a consistent JSON payload the model can consume reliably.
- AI coding. Clinical NLP and ML models identify diagnoses and procedures, map them to ICD-10 and CPT codes, recommend modifiers, and attach a confidence score to each.
- DFT back to billing. Mirth packages the predicted codes into a standard HL7 DFT (Detail Financial Transaction) message and delivers them to the billing module to start claim generation.
What the Engine Reads — and Returns
The integration layer extracts structured clinical data from the inbound HL7 messages and returns a structured prediction set. This is the same custom healthcare software development approach we apply across EHR-connected products: map the source data carefully, preserve clinical meaning, and make every output auditable.
HL7 message types in scope
| HL7 message | Clinical information carried |
|---|---|
| ADT | Patient demographics, encounter details, admit/discharge information. |
| ORU | Lab results, clinical observations, diagnostic findings, provider notes (OBX). |
| MDM | Chart notes, discharge summaries, procedure notes, provider documentation. |
| ORM | Clinical orders — lab, procedure, and medication orders. |
| DFT (outbound) | AI-predicted ICD/CPT/HCPCS codes returned to the billing system. |
The engine's output
| Output | Description |
|---|---|
| ICD-10 codes | Diagnosis codes predicted from notes, DG1 segments, and lab findings. |
| CPT codes | Procedure codes from PR1 segments, documentation, and clinical context. |
| HCPCS codes | Where applicable — DME, drugs, supplies. |
| Modifiers | CPT modifiers recommended from clinical context. |
| Confidence score | A 0–1 score per prediction that drives the human-review threshold. |
Human-in-the-Loop by Design
Autonomy does not mean unsupervised. Predictions that fall below a configured confidence threshold are automatically flagged for the medical coding team. Edge cases, complex encounters, and ambiguous documentation are never submitted to billing without human validation — which keeps the high-volume routine work automated while focusing expert coders on the exceptions.
Why an HL7-First Approach Scales
Because the engine consumes the HL7 messages an EHR already emits, it is compatible with virtually any HL7-capable EHR — Epic, Cerner, athenahealth and others — without per-vendor API development. The integration reads only what the EHR sends; it never modifies clinical data. That keeps each new facility a configuration exercise rather than a fresh engineering project, which is exactly what lets a coding product scale across providers. The same pattern powers our healthcare AI agents that automate other clinical and revenue-cycle workflows.
The Outcome
The architecture closes the gap between care delivery and billing. Coding begins the instant an encounter is signed rather than waiting in a coder's queue; predictions are consistent and auditable, with a confidence score and review trail on every code; and routine, high-volume encounters can be handled automatically while humans focus on the exceptions the model flags.
- Faster claim submission — coding starts at encounter closure, shrinking the lag between care and billing.
- Fewer transcription errors — data the EHR already produced is never re-keyed.
- Auditable compliance — confidence scores and review trails on every prediction.
- EHR-agnostic scale — one integration pattern, any HL7-capable EHR, multiple facilities.
Why Nirmitee
Healthcare is the only industry we serve. We have built 100+ AI-enabled healthcare products — production systems, not POCs — with 70+ healthcare-focused engineers. We have EHR integration experience with Epic, Cerner, Allscripts, and athenahealth, are HL7 v2 and HL7 FHIR experienced, and ship on a FHIR R4 native architecture. Nirmitee.io is HIPAA-compliant, SOC 2 Type II, and ISO 27001 certified.
This case study describes Nirmitee.io engineering patterns. It does not include actual Protected Health Information (PHI). All client-data examples are synthetic or de-identified per HIPAA Safe Harbor. Client identity withheld under NDA.
