AI Clinical Documentation Case Study: 59% Fewer Denials

Physicians at the client's hospitals were spending close to two hours on documentation for every hour of direct patient care. That quiet imbalance is the operational reality this AI clinical documentation case study examines, and most healthcare systems recognise it the moment they read it. Across the network, discharged charts sat unbilled for an average of 11.4 days while a coding team that never fully cleared its backlog worked through them one at a time. Every delayed chart was deferred revenue, and every ambiguous note was a future denial waiting to be written.

The client is a leading healthcare enterprise operating several acute care facilities and a large outpatient footprint. They engaged KriraAI to attack the documentation and coding bottleneck at its root rather than adding more staff to a broken process. This blog walks through the problem exactly as it existed, the production system KriraAI designed and shipped, the full architecture layer by layer, the delivery journey with the real obstacles we hit, and the results the client measured across the first eight months of live operation. This implementation expands on the broader transformation discussed in AI in Healthcare: How KriraAI Transformed Clinical Operations, where production AI improved both clinical efficiency and operational performance. 

The Problem Behind This AI Clinical Documentation Case Study

The client was not short on data. Every encounter generated progress notes, discharge summaries, nursing documentation, lab results, and structured orders inside their electronic health record. The problem was that this clinical narrative existed as unstructured text that no downstream system could read with any precision. Coders had to open each chart, interpret the physician's intent, reconcile it against structured fields, and then assign the correct diagnosis and procedure codes by hand.

That manual translation step was the single point where quality, speed, and revenue all collapsed together. A certified coder was reviewing roughly 3.2 inpatient charts per hour, and complex specialty charts took far longer. When documentation was incomplete or contradictory, coders raised a clinical documentation integrity query to the treating physician and then waited, sometimes for days, for a reply that often never fully resolved the gap.

Where the revenue was leaking

The financial damage showed up in three predictable places, and each one compounded the others.

1. The initial claim denial rate sat at 12.8 percent, and a large share of those denials traced directly back to documentation specificity and coding errors rather than genuine payer disputes.

2. Discharged Not Final Billed days averaged 11.4, which meant tens of millions of dollars in earned revenue were locked in unbilled accounts at any given moment.

3. Undercoding on complex cases quietly stripped legitimate reimbursement from encounters where the clinical work had been performed but never precisely captured in the codes submitted.

Beyond the numbers, the human cost was corrosive. Physicians resented documentation that felt like clerical punishment, and coders burned out under a backlog that reset every morning. The competitive pressure made the status quo untenable, because payers were tightening documentation requirements every year while margins compressed. The client needed a system that could read clinical language the way an expert coder does, ground every decision in current coding rules, and return its work inside the clinician's existing workflow. That is the engagement KriraAI was brought in to deliver.

What KriraAI Built To Replace Manual Coding And Documentation

KriraAI is an enterprise AI engineering firm that builds production machine learning systems for regulated industries, and this engagement sat squarely in that discipline. We designed and delivered a clinical documentation intelligence platform that reads the full clinical narrative of an encounter, extracts the medically relevant entities, and produces grounded, evidence-linked coding recommendations along with real-time documentation gap alerts. The platform did not replace certified coders or physicians. It removed the mechanical translation burden so that both could operate at the top of their expertise.

At the centre of the platform sits a clinical NLP RAG pipeline. When a chart closes, the system ingests every note attached to the encounter and runs a domain-adapted transformer encoder that performs medical named entity recognition across conditions, procedures, medications, laterality, acuity, and clinical status. Those extracted entities become a structured clinical profile of the encounter rather than a wall of free text. This is the representation the rest of the system reasons over.

The clinical NLP RAG pipeline then retrieves the specific coding rules that apply to that profile. A retrieval layer queries a vector index built over ICD-10-CM tabular guidance, CPT descriptors, MS DRG logic, and the payer-specific policies that govern this network's contracts. A generation model produces candidate codes conditioned strictly on the retrieved evidence, so every recommendation carries a citation back to the exact guideline and the exact span of clinical text that justified it. This grounding is what made the output trustworthy to a compliance team.

Every recommendation passes through a confidence calibration layer before a human ever sees it. High confidence codes on clean, unambiguous outpatient encounters are routed to autonomous medical coding, where the system finalises the code set, and only a sampled subset is reviewed. Lower confidence or high complexity charts are routed to a coder assist queue, where the codes arrive prepopulated with supporting evidence and the coder confirms, edits, or overrides. This selective autonomy is the core of the design. KriraAI built the system to know precisely when it should act alone and when it should defer to a human, and that boundary is enforced by measured thresholds rather than optimism.

Inside The Solution Architecture Layer By Layer

The architecture behind this AI clinical documentation case study was engineered as a hardened production system from the first line of code, not as a pilot that would later be rewritten. It runs entirely inside the client's private cloud tenancy with no public endpoints. The following subsections walk through each layer, what it does, and why we designed it the way we did.

Data Ingestion And Pipeline

The ingestion layer had to capture clinical events the moment they occurred without adding load to the production EHR. We implemented change data capture using Debezium against the operational database replicas, streaming committed changes into Apache Kafka as an immutable event log. High-volume clinical documents and HL7 v2 feeds landed on the same backbone, while batch extraction handled historical corpora for model training. This gave us one consistent event spine for both real-time and historical data.

Once on the stream, records passed through Apache Flink for stateful processing. Flink handled schema normalisation into a common clinical model, entity resolution to bind every note to the correct patient and encounter, and deidentification of protected health information before any data reached the training environment. Embeddings for retrieval were generated at ingestion time so that documents were index-ready the moment they arrived. Apache Airflow orchestrated the batch DAGs for corpus preparation, retraining data assembly, and evaluation refreshes on a scheduled cadence.

AI And Machine Learning Core

The core combined three specialised models rather than forcing one model to do everything. A biomedical transformer encoder handled clinical named entity recognition and was fine-tuned on the network's deidentified charts using supervised fine-tuning with LoRA adapters for efficiency. A retrieval model trained with contrastive learning aligned clinical language embeddings with the language of coding guidelines, which is what allowed the system to match a physician's phrasing to the correct codeable concept. A generation model produced the final code recommendations under constrained decoding that restricted outputs to valid, active code sets.

We refined the recommendation quality using reinforcement learning from human feedback, where certified coders and clinical documentation integrity specialists ranked candidate outputs, and their preferences shaped the reward model. Serving ran on vLLM and TensorRT LLM across an NVIDIA GPU cluster on Kubernetes, with quantised weights to hold latency down under production load. Retrieval was served from a vector index using HNSW graphs for fast approximate nearest neighbour search. Distributed training used PyTorch with fully sharded data parallelism.

Integration Layer

The platform was worthless if coders and physicians had to leave their tools to use it, so the integration layer was treated as a first-class engineering concern. KriraAI implemented the full FHIR AI integration against the client's EHR, reading encounter data through FHIR R4 resources and writing structured coding recommendations back as DocumentReference and Claim resources. A SMART on FHIR application embedded the coder assist interface directly inside the EHR, so recommendations appeared where the work had already been done.

Internally, the services communicated over gRPC for low-latency calls between the retrieval, generation, and calibration components. External contracts were exposed through versioned REST and GraphQL APIs so downstream revenue cycle systems could consume outputs predictably. An event-driven design connected AI outputs to business workflows through Kafka, and webhook triggers pushed flagged documentation gaps into the clinical documentation integrity worklist the instant they were detected. This is how a model prediction became a task on a real person's screen.

Monitoring And Observability

A clinical coding system that silently degrades is a liability, so the MLOps layer was built to catch drift before it reached a claim. KriraAI instrumented data drift detection using population stability index and KL divergence across incoming feature distributions, with alerts firing when the index crossed a threshold of 0.2. Model quality was tracked continuously against a held-out gold standard set of expert-coded charts, and any decline against that baseline raised an incident. Feature distribution shift and specialty mix changes were monitored separately, because a new service line could quietly move the input distribution.

Operationally, we tracked latency at the p50, p95, and p99 percentiles, along with retrieval hit rates and autonomous coding acceptance rates. MLflow served as the experiment tracker and model registry, Evidently powered the drift reports, and Prometheus with Grafana and OpenTelemetry gave us traces and dashboards across the whole system. Automated retraining triggers fired when performance crossed defined thresholds, assembling a fresh training set from recent verified charts and promoting a candidate model only after it beat the incumbent on evaluation.

Security And Compliance

Because every record was protected health information, security was designed into the architecture rather than added at the end. The platform ran inside a private virtual private cloud with no public endpoints, and all model inputs and outputs were encrypted end to end. KriraAI implemented role-based access control with attribute-level data masking, so a user only ever saw the fields their role permitted. Every access and every model decision were written to an immutable, append-only audit store, giving compliance a complete and tamper-evident record.

The build honoured HIPAA and HITECH requirements throughout, with a signed business associate agreement governing the engagement and deidentification enforced before any data entered the training path. Data residency stayed within the client's chosen region, and access to the training environment was tightly scoped and logged. This is the layer that lets the client's compliance office sign off on autonomous medical coding with confidence.

Delivery And User Interface

The delivery layer met two very different audiences. Coders worked inside a React-based assist interface embedded in the EHR through SMART on FHIR, where each recommended code arrived with its confidence score and a clickable link to the exact clinical evidence behind it. A separate clinical documentation integrity dashboard surfaced documentation gaps, prioritised by financial and compliance impact, so specialists could act on the highest-value queries first. Physicians received concise documentation nudges inside their own workflow rather than a separate inbox.

The Technology Stack And Why We Chose It

Every technology in this build was selected against the client's existing environment, their scale, and their regulatory constraints, not chosen for novelty. The stack below is organised by layer with the reasoning behind each decision.

1. Ingestion and streaming used Apache Kafka with Debezium change data capture and Apache Flink, chosen because the client needed both real-time and historical processing on one backbone without touching the production EHR database directly.

2. Orchestration used Apache Airflow, selected for its mature scheduling and the client's existing operational familiarity with DAG-based batch workflows.

3. The model layer used PyTorch with fully sharded data parallelism for training and LoRA adapters for efficient fine-tuning, because full retraining of large models on every update was neither necessary nor cost-effective.

4. Serving used vLLM and TensorRT LLM on NVIDIA GPUs orchestrated by Kubernetes, chosen to hold p95 latency low while serving quantised models under concurrent hospital load.

5. Retrieval used a vector index with HNSW graph search, selected over flat search because recall at low latency mattered more than exhaustive precision for interactive coder workflows.

6. Integration used FHIR R4, SMART on FHIR, gRPC internally, and versioned REST and GraphQL externally, chosen so the platform met the EHR's standards rather than forcing a custom bridge.

7. The MLOps layer used MLflow, Evidently, Prometheus, Grafana, and OpenTelemetry, selected as a proven open stack that the client's own engineers could operate after handover.

KriraAI deliberately favoured open standards and open source components wherever they met the bar, because this client wanted to own and operate the platform long term rather than depend permanently on a vendor. Every managed service used was HIPAA-eligible and deployed inside the client's tenancy. The result was a stack that the client's team could inspect, extend, and run themselves.

How We Delivered It, The Implementation Journey

The engagement ran across a structured delivery lifecycle, and KriraAI treated each phase as a gate rather than a formality. What follows is an honest account of the journey, including the obstacles that forced rework, because a real production build never runs clean from end to end.

Discovery, design, and the data reality

Discovery and requirements ran for the first four weeks, pairing our engineers with the client's coders, physicians, and revenue cycle leaders. Architecture design followed, where we mapped the FHIR AI integration surface and set the confidence thresholds that would govern autonomous action. The first serious obstacle appeared during data foundation work. Clinical notes were far messier than the schema suggested, with scanned documents, inconsistent templates, and structured fields that frequently disagreed with the narrative text.

We resolved the data quality problem by strengthening the ingestion transforms, adding optical character recognition for scanned content, and building an entity resolution step that reconciled contradictions between structured and unstructured sources. This work was slower than planned, and we adjusted the timeline honestly rather than shipping a model trained on dirty inputs. Getting the data foundation right was the difference between a system coders trusted and one they would have ignored.

Development, validation, and go-live

Model development surfaced the second challenge. Early evaluation showed strong performance on common encounters but a real accuracy gap on rare specialties where labelled examples were scarce. KriraAI closed that gap with targeted fine-tuning and an active learning loop, where the specialist coders reviewed exactly the uncertain cases the model most needed, and those corrections fed the next training round. The third challenge was integration, where FHIR write-back constraints and EHR API rate limits forced us to redesign the delivery path around batched, back-pressure-aware writes.

Testing and validation ran the system in shadow mode against live charts for several weeks, comparing every recommendation against the certified coder's final decision before a single output influenced a real claim. Only after the system matched expert performance on a held-out set of 20,000 charts did we begin a phased deployment, starting with two pilot units and expanding across the network as confidence held. Handover included full MLOps enablement, so the client's own engineers could operate monitoring, retraining, and incident response. KriraAI built the platform to be owned, not rented.

The Results The Client Achieved

The client measured outcomes across the first eight months of live operation, and the results held across both clinical and financial dimensions. The initial claim denial rate fell from 12.8 percent to 5.3 percent, a 59 percent relative reduction, and denials attributable to documentation and coding errors dropped the most sharply. This single shift is the clearest evidence of AI claim denial reduction in the engagement, and it materially moved the network's revenue integrity. These operational improvements complement the outcomes presented in How a Mid-Size Hospital Reduced Diagnostic Errors by 28% with Machine Learning, where AI improved diagnostic accuracy through predictive clinical models. 

Coding throughput and cycle time improved just as decisively. Effective coder throughput rose from 3.2 to 7.8 charts per hour once recommendations arrived prepopulated with evidence, and 46 percent of eligible outpatient encounters were finalised through autonomous medical coding with only sampled human review. Discharged Not Final Billed days fell from 11.4 to 4.1, releasing a large volume of previously locked revenue into billing far faster. Documentation gaps that once took days to resolve were surfaced and cleared the same day.

On accuracy, the recommendation engine reached 91.4 percent top 1 code accuracy and 96.2 percent top 3 accuracy against the certified coder gold standard on the held-out validation set. In production, the platform served coder suggestions at a p95 latency under two seconds. The combined effect of recovered undercoding, reduced denials, faster billing, and higher coder productivity produced an annualised net revenue impact of roughly 9.6 million dollars. These are confirmed outcomes from a completed and operational engagement.

What This Architecture Makes Possible Next

The platform was engineered to grow, so rising data volume is an operational parameter rather than a redesign trigger. The streaming ingestion, distributed serving, and vector retrieval layers all scale horizontally on Kubernetes, which means additional facilities or higher encounter volume are absorbed by adding capacity rather than rebuilding the system. When new payer policies or coding updates arrive, they enter through the retrieval corpus and the automated retraining loop, so the platform stays current without a fresh build.

The same foundation supports new use cases without disturbing what already runs in production. The clinical NLP RAG pipeline that grounds coding can extend to prior authorisation support, denial appeal drafting, and quality measure abstraction, because each reuses the same extraction and retrieval spine. The client's AI roadmap over the next two to three years builds directly on this base, layering new capabilities onto shared infrastructure rather than standing up isolated systems. That reuse is where the compounding return lives. Many healthcare organizations work with an AI consulting company to identify the highest-value automation opportunities before expanding AI across clinical operations. 

For other healthcare organisations, the transferable lesson is architectural discipline. Grounding every AI decision in retrieved, citable evidence, enforcing a measured boundary between autonomous and human-reviewed work, and instrumenting drift detection from day one are what separate a system that survives in production from a demo that never leaves the pilot. Any network with a documentation and coding bottleneck can apply the same pattern KriraAI proved here.

Conclusion

Three insights define this engagement. Technically, grounding every AI decision in retrieved, citable evidence and enforcing a measured boundary between autonomous and human-reviewed work is what made a clinical coding system safe enough to run in production. Operationally, the win came from removing a mechanical translation burden so that coders and physicians could work at the top of their expertise rather than fighting their tools. Strategically, building the platform on open standards inside the client's own tenancy meant they gained an asset they own and can extend, not a dependency they rent.

KriraAI brings this same engineering rigour and delivery discipline to every client engagement, treating each system as a hardened production build from the first design session through handover and MLOps enablement. We do not ship pilots that quietly need rewriting, and we do not hide model decisions behind a black box. If your organisation is carrying its own version of the documentation and coding bottleneck described in this AI clinical documentation case study, bring that challenge to KriraAI and we will architect the system that solves it.