Skip to content

Porting the CMS MS-DRG Grouper to Zig: A High-Performance Open-Source Engine

April 6, 2026 — By the Bedrock Billing Engineering Team

In the healthcare claims processing and revenue cycle management (RCM) world, the Medicare Severity Diagnosis Related Group (MS-DRG) grouper is the indisputable engine of inpatient reimbursement. When a hospital discharges a Medicare patient, a massive array of diagnoses (ICD-10-CM), procedures (ICD-10-PCS), demographics, and discharge statuses are fed into a sprawling logical tree to determine the precise MS-DRG classification. This single number dictates the base payment the hospital facility will receive.

For years, the industry standard has been the official CMS MS-DRG Grouper. When CMS modernized this software from its original COBOL roots to Java, it was a monumental achievement for health tech. The Java iteration provided robust, class-based predictability and algorithmic accuracy to a complex regulatory engine.

However, as the healthcare technology landscape shifts toward serverless architectures, real-time streaming, and microservices, integrating a heavy JVM process into modern Python and Node.js data pipelines has become increasingly challenging.

To bridge this gap, we are thrilled to announce mz-drg: a high-performance, open-source reimplementation of the CMS MS-DRG classification engine, written natively in Zig with seamless Python bindings. It is a 100% matched, line-by-line port of the original logic capable of processing over 11,000 claims per second via a simple pip install msdrg.

Our unified suite now encompasses not just the MS-DRG logic, but the structural Medicare Code Editor (MCE) and rapid ICD-10 Code Conversion. Here is the story behind mz-drg, why we chose Zig, and how we restructured the data pipeline to achieve near-instantaneous processing capabilities.

1. The Challenge in Healthcare Data Integration

The official Java Grouper is fantastic for traditional batch-processing environments. But when scaling it inside a modern REST API or streaming data architecture, engineering teams face significant friction points:

  1. JVM Warmup & Memory Footprint: The Java grouper loads its reference data—thousands of ICD-10 definitions, MDCs, and DRG formulas—from Google Protobuf format directly into memory HashMaps. While this makes subsequent lookups fast, it bloats the JVM heap size and causes a noticeable startup delay before a single claim can be grouped.
  2. Integration Complexity: Calling Java objects from Python requires JNI bridges like JPype. Managing classpath dependencies inside Python containers is notoriously difficult and makes developer environments heavy and brittle.
  3. Throughput Ceilings: The overhead of object serialization and method dispatch logic capped our throughput on a standard laptop processor to roughly ~500 claims per second.

We needed the next evolutionary step: a native engine with zero startup lag that could run cleanly as a Python extension without external dependencies, processing claims fast enough to handle massive real-time analytics pipelines.

2. Why We Chose Zig for Healthcare Infrastructure

When evaluating systems languages for a strict port of the Java codebase, Zig emerged as the clear winner over Rust or C++.

  • Seamless C ABI & Python Interop: Zig makes it trivial to compile a shared library (.so, .dll, or .dylib) that cleanly exports a C API. Using Python's native ctypes and memory-safe abstractions, we bound to the Zig engine immediately without writing boilerplate C-extension wrappers.
  • Effortless Cross-Compilation: Our architecture needs to run securely in any clinical or cloud environment. Zig's build system allowed us to cross-compile native binaries for x86_64 Linux servers, Windows desktops, and AArch64 macOS dev environments directly from a single compilation pass.
  • Control over Memory: Zig's explicit memory allocators gave us perfect granular control over exactly how memory-mapped data structures were handled at runtime, eliminating garbage collection pauses and ensuring deterministic throughput.

3. Under the Hood: The Protobuf to Memory-Map Pipeline

The most dramatic performance gain in mz-drg isn't solely the execution language speed—it's how we fundamentally changed the reference data architecture.

To eliminate startup lag, we built a pipeline to bypass the runtime loading phase entirely.

  1. Extraction via JPype: We wrote Python scripts that boot the reference CMS Java .jar files in memory using JPype. The script interrogates the internal Java logic trees and serializes the raw logic into intermediate CSV files.
  2. Native Compilation: A secondary script processes these CSV files into highly optimized, pre-sorted native binary files.
  3. Zero-Overhead Memory Mapping: When mz-drg is imported into your Python application, the Zig engine does not parse or deserialize objects. Instead, it memory maps (mmap) these sorted .bin files directly from disk into virtual memory.

By executing efficient binary searches O(log n) directly against the memory-mapped buffers, mz-drg skips data hydration. The memory footprint drops drastically, the startup is instantaneous, and claim routing latency shrinks to microseconds.

4. Expanding the Pipeline: The Medicare Code Editor (MCE)

Since the initial release of the MS-DRG grouper, we've expanded mz-drg to include a full native port of the Medicare Code Editor (MCE).

The MCE validation step strictly precedes MS-DRG grouping. It detects invalid ICD codes, sex and age clinical conflicts, unacceptable principal diagnoses, and non-covered procedure flags. By applying the same mmap pattern, we've bundled both engines into a single library. This lets you validate and group in a single, memory-safe pass:

import msdrg

claim = {
    "discharge_date": 20250101, "age": 65, "sex": 0, "discharge_status": 1,
    "pdx": {"code": "I5020"}, "sdx": [{"code": "E1165"}], "procedures": [],
    "version": 431
}

with msdrg.MceEditor() as mce, msdrg.MsdrgGrouper() as g:
    mce_result = mce.edit(claim)  # Detects code conflicts/errors
    drg_result = g.group(claim)   # Assigns the MS-DRG

5. Bridging Fiscal Years: ICD-10 Code Conversion

A notoriously painful aspect of historical claims analytics is that ICD-10-CM and PCS codes change annually every October 1st. You cannot accurately group a 2024 claim using 2026 MS-DRG logic unless you forward-map the original diagnosis and procedure codes to their modern equivalents.

To solve this, mz-drg now features a blazing-fast ICD-10 Converter built directly into the core library. This utilizes the official CMS conversion tables to seamlessly map codes between fiscal year versions.

You can securely map codes natively using the IcdConverter standalone class:

import msdrg

with msdrg.IcdConverter() as conv:
    # Convert a DX code from FY2025 to FY2026
    new_code = conv.convert_dx("A000", source_year=2025, target_year=2026)

    # Batch conversion for large arrays
    results = conv.convert_dx_batch(["I5020", "E1165"], source_year=2025, target_year=2026)

Even better, we deeply integrated this into the MS-DRG grouper pipeline. Simply pass the source_icd_version directly on your claim payload, and the engine will seamlessly convert all codes in-memory before running the MCE and DRG formulas:

with msdrg.MsdrgGrouper() as g:
    result = g.group({
        "version": 431,             # Target DRG formula: FY2026
        "source_icd_version": 2025,  # Claim origin: FY2025 codes
        "pdx": {"code": "A000"},
        # ...
    })

6. Open-Sourcing the Future of Medical Logic

Building mz-drg was a line-by-line verification effort validated against over 50,000 reference claims. Today, we achieve a 100% output match rate against the standard Java application across MS-DRG formulations, MDC routing, and HAC modifiers.

We are deeply grateful for the foundational open-source work provided by CMS. We open-sourced mz-drg to continue that tradition and empower RCM developers to build faster, secure, and resilient healthcare tech stacks. By bringing this deterministic logic into a high-performance, drop-in Python module, we aim to accelerate the broader ecosystem of medical APIs, EHR plugins, and analytics engines.

pip install msdrg

Check out the repository on GitHub to explore the Zig codebase, integrate the Python tools, and help to advance modern healthcare engineering!