Digital Registrar: A Schema-First Framework for Multi-Cancer Privacy-Preserving Pathology Abstraction via Local LLMs

This paper presents "Digital Registrar," a schema-first framework that leverages local large language models and a CAP-aligned clinical ontology to accurately transform free-text surgical pathology reports into structured, privacy-preserving registry data across multiple cancer types, achieving high accuracy and generalizability while decoupling clinical logic from specific AI models.

The Gist

Imagine you have a massive library of medical reports. These reports are written by expert pathologists who describe cancer in incredible detail—like a master chef writing a complex recipe for a dish. However, these recipes are written in long, flowing paragraphs of free text.

Now, imagine you need to feed this information into a computer system to track cancer trends, help doctors make decisions, or run research. The problem is, computers don't speak "flowing paragraphs." They speak "structured data" (like a spreadsheet with specific columns).

Currently, getting that information from the paragraph into the spreadsheet is like trying to manually copy a 50-page novel into a 10-row Excel sheet. It takes humans a long time, it's boring, and mistakes happen.

This paper introduces a solution called "Digital Registrar." Think of it as a super-smart, privacy-focused robot librarian that can read those messy paragraphs and instantly fill out the spreadsheet perfectly, without ever needing to send the data to the cloud.

Here is how it works, broken down with some simple analogies:

1. The "Blueprint" First (Schema-First)

Most AI research tries to teach a robot to "guess" what to write. This paper does the opposite. They first built a strict blueprint (called a "Schema").

• The Analogy: Imagine you are building a house. Instead of letting the builder just "wing it," you give them a strict architectural plan with specific slots for windows, doors, and bricks.
• In the Paper: The researchers used official medical rules (from the College of American Pathologists) to create a rigid digital form. The AI isn't allowed to just "chat"; it must fill in specific boxes like "Tumor Size," "Lymph Nodes," or "Surgery Margins." If the AI tries to write something that doesn't fit the box, the system rejects it. This ensures the data is always organized correctly, no matter which AI model is doing the reading.

2. The "Universal Translator" (Model Agnostic)

The researchers didn't just build this for one specific AI brain. They built a system where the "brain" can be swapped out.

• The Analogy: Think of the "Digital Registrar" as a car chassis. You can put a V8 engine in it, or a hybrid engine, or an electric motor. As long as the engine fits the chassis, the car drives.
• In the Paper: They tested three different AI models (gpt-oss, qwen, and gemma). The system worked with all of them. This is huge because AI models change fast. If one model becomes outdated, you can swap in a new one without having to rebuild the whole system.

3. The "Local Librarian" (Privacy-Preserving)

Usually, to use a smart AI, you have to send your data to a giant server farm (the cloud). But medical data is super sensitive. You don't want patient names or cancer details leaving the hospital.

• The Analogy: Instead of mailing your secret diary to a famous editor in New York to get it typed up, you hire a trusted typist who works in your own basement. The diary never leaves the house.
• In the Paper: The system runs on a single, powerful computer (a workstation with a big graphics card) right inside the hospital. The data never leaves the building. This keeps patient privacy safe while still using powerful AI.

4. The "Speed vs. Power" Test

The researchers had to figure out which "engine" (AI model) was best for this job. They wanted something fast enough to process a report in under a minute but smart enough to be accurate.

• The Analogy: They tested three cars.
  • Car A (gpt-oss): A sleek sports car. It was the fastest and most accurate. It could read a complex report in 40–70 seconds.
  • Car B (qwen): A heavy truck with a powerful engine. It was accurate but slow (taking over 2 minutes) because it was too heavy for the single computer.
  • Car C (gemma): A standard sedan. It was okay, but not as fast or accurate as the sports car.
• The Result: They chose the "sports car" (gpt-oss) because it offered the perfect balance of speed and smarts for a hospital computer.

5. The Results: "Registry-Grade" Accuracy

They tested this system on nearly 900 real medical reports and even 150 reports from a different country (to see if it worked on different writing styles).

• The Score: The system got it right 94.3% of the time.
• The "Critical" Stuff: It was almost perfect at finding the most important numbers, like whether a tumor had spread to lymph nodes or if the surgery margins were clean.
• The Takeaway: It's not just "good enough"; it's accurate enough to be trusted by doctors and cancer registries.

Why Does This Matter?

Before this, hospitals had to hire humans to manually type cancer data into databases. This was slow and expensive.

The "Digital Registrar" changes the game by:

1. Saving Time: It turns hours of manual work into seconds of computer time.
2. Saving Money: It runs on standard hospital computers, not expensive supercomputers.
3. Protecting Privacy: It keeps patient data safe inside the hospital walls.
4. Future-Proofing: Because it uses a strict "blueprint," it will work even as AI technology evolves.

In short, this paper presents a smart, secure, and fast way to turn messy medical stories into clean, usable data, helping doctors and researchers understand cancer better without compromising patient privacy.

Technical Summary

1. Problem Statement

Surgical pathology reports contain the most granular diagnostic data for cancer (staging, margins, biomarkers, lymph nodes) but are predominantly stored as unstructured free text. This creates a "translational gap" that hinders automated cancer registry entry, secondary analytics, and interoperability.

• Current Limitations: Existing Large Language Model (LLM) approaches often focus on narrow extraction tasks or specific model demonstrations. They frequently lack a durable, clinically governed schema, leading to outputs that are hard to validate, compare across institutions, or integrate into longitudinal data systems.
• The Core Challenge: The bottleneck is not just extraction accuracy, but representation. A system must preserve organ-specific semantics, nested relationships, and variable-length structures (e.g., lymph node groups) without collapsing clinical context. Additionally, there is a need for privacy-preserving deployment where institutions can run models on-premise without sending Protected Health Information (PHI) to external clouds.

2. Methodology

The authors propose Digital Registrar, a "schema-first" framework that decouples clinical logic from specific AI models.

A. Schema-First Clinical Ontology

• Foundation: The system is built on a College of American Pathologists (CAP)-aligned clinical ontology.
• Structure: Implemented as strictly typed, hierarchical JSON schemas. It consists of:
  1. A Universal Core Layer (common attributes like eligibility and tumor site).
  2. Ten Organ-Specific Extension Layers (covering Breast, Lung, Colorectal, Prostate, etc.) with 193 total registry fields.
• Design: The schema handles complex structures (e.g., repeating lymph node stations, variable surgical margins) and enforces strict typing (Literal, bool, int, None) to ensure deterministic validation.

B. Extraction Pipeline (DSPy Framework)

• Architecture: The pipeline uses the DSPy 2.1 framework, which allows for model-agnostic orchestration.
• Workflow:
  1. Eligibility Classification: Determines if a report is a cancer excision (vs. biopsy/benign).
  2. Organ Detection: Identifies the specific organ system.
  3. Organ-Specific Extraction: Uses distinct DSPy modules (e.g., BreastCancerMargins, BreastCancerLN) to extract structured JSON.
• Inference: The system operates in a one-shot manner (no fine-tuning or few-shot prompting). It processes reports in a single forward pass.

C. Hardware and Model Strategy

• Privacy: Designed for on-premise deployment on a single high-end workstation GPU (NVIDIA RTX A6000, 48 GB VRAM).
• Model Agnosticism: The framework was benchmarked against three open-weight models to prove independence from specific model weights:
  • gpt-oss:20b (Sparse Mixture-of-Experts)
  • qwen3-30b-A3B (Sparse MoE)
  • gemma3:27b (Dense)
• Selection: gpt-oss:20b was selected as the optimal engine due to the best balance of speed (40–70s/report) and accuracy.

3. Key Contributions

1. Schema-First Abstraction: The primary contribution is the clinical ontology layer, which is designed to outlast specific AI model generations. It ensures that the logic of what to extract and how to structure it remains consistent, even as underlying models evolve.
2. Model-Agnostic Privacy: Demonstrates that high-fidelity extraction can be achieved entirely on local hardware (single 48GB GPU), eliminating the need for cloud-based PHI transmission.
3. Complex Structure Handling: Successfully extracts variable-length, nested structures (e.g., multiple lymph node stations, detailed margin descriptions) that flat-field extraction methods typically fail to capture.
4. Open Source & Reproducibility: The pipeline, schemas, and DSPy signatures are made available, promoting reproducibility in medical AI.

4. Results

The framework was evaluated on 893 internal reports (2023–2024) and an external validation cohort of 150 TCGA reports.

• Overall Accuracy:
  • Internal Cohort: Achieved a mean exact-match accuracy of 94.3% across all 193 registry fields using gpt-oss:20b.
  • External (TCGA) Cohort: Maintained high generalizability with 92.4% accuracy, demonstrating robustness across different institutional reporting styles without fine-tuning.
• Critical Clinical Fields:
  • Breast Biomarkers: Near-perfect accuracy (ER/PR/HER2/Ki-67).
  • Surgical Margins: 91.2% mean accuracy for positivity determination.
  • Lymph Nodes: >80% concordance for total node counts; high accuracy for station-level details in well-defined basins (e.g., breast, liver).
• Efficiency:
  • gpt-oss:20b processed complex reports in 40–70 seconds.
  • It outperformed the larger qwen3-30b (140–200s) and gemma3:27b (50–130s) in speed while maintaining the highest accuracy.
• Triage Performance: The eligibility classifier showed near-perfect sensitivity (missing only 1 of 694 eligible cases) and high specificity, effectively filtering out non-eligible reports.

5. Significance and Future Directions

• Interoperability: By converting narrative text into registry-grade structured JSON, this framework bridges the gap between clinical documentation and data science, enabling automated cancer surveillance and quality assessment.
• Sustainability: The "schema-first" approach ensures that the system remains valid even as LLM architectures change, solving the "model obsolescence" problem common in AI research.
• Privacy: It provides a viable path for hospitals to leverage advanced AI for data abstraction without compromising patient privacy via cloud APIs.
• Future Work: The authors envision extending this framework into a multimodal system, integrating genomic data and digital pathology images (e.g., using models like PathChat+) to correlate histologic patterns with molecular markers for integrated diagnostics.

In conclusion, Digital Registrar represents a shift from "model-centric" extraction to "ontology-centric" abstraction, offering a portable, privacy-preserving, and highly accurate solution for transforming unstructured pathology reports into actionable, structured cancer data.