Clinical Registry Intelligence

Clinical Registry Intelligence is the kind of work that sits underneath reliable applied AI. Before extraction quality, analytics, or downstream modeling can matter, the data contract has to be stable enough to trust.

Overview

At Carta Healthcare, I owned end-to-end ETL and clinical NLP pipelines that moved heterogeneous healthcare data into forms that registry workflows could actually use. The work combined ingestion, schema alignment, transformation logic, validation, API-oriented processing, and LLM-assisted extraction for information that could not be captured cleanly with deterministic rules alone.

Context

Carta operates in a domain where operational value depends on turning difficult clinical data into structured registry-ready signals. Inputs arrived from multiple sources and in multiple shapes: structured fields, semi-structured exports, and free-text clinical documentation. The technical challenge was not only extracting information, but building a workflow that downstream registry and analytics teams could rely on without reinterpreting each source separately.

Problem

Clinical data is rarely neat enough for direct use. Important fields may be missing, encoded differently across systems, or embedded in narrative documentation. Without a normalization layer, each downstream consumer inherits ambiguity, and any ML or analytics system built on top becomes harder to validate, debug, and maintain.

For registry workflows specifically, that created three compounding issues:

• heterogeneous source schemas needed to map into a stable representation
• clinically relevant facts were often present only in unstructured text
• downstream teams needed outputs that were standardized, inspectable, and operationally usable

System Design

I treated the problem as a workflow design problem rather than a single-model problem.

The system centered on ETL pipelines that ingested heterogeneous clinical inputs, normalized them into HL7- and FHIR-aligned structures, and prepared them for downstream extraction and registry consumption. That meant combining parsing, field mapping, schema validation, and transformation logic in a way that made outputs consistent across source systems rather than only within one source.

On top of that normalized layer, I integrated clinical NLP and LLM-assisted extraction for information that could not be captured reliably from structured data alone. The important design choice was separation of concerns: normalization first, extraction second, downstream consumption third. That kept the system easier to reason about, easier to review, and less likely to collapse into source-specific cleanup logic.

Sanitized Workflow Snapshot

The practical shape of the workflow looked like this:

1. ingest source data from structured fields, exports, and narrative clinical text
2. map fields into a stable internal representation with explicit validation checks
3. normalize outputs into HL7/FHIR-aligned structures for downstream use
4. apply deterministic extraction where rules were sufficient
5. apply LLM-assisted extraction only where clinical narrative contained important missing signal
6. expose inspectable outputs for registry operations and downstream analytics

That sequence mattered. It prevented extraction logic from becoming a substitute for basic data engineering discipline.

Key Technical Decisions

One important decision was to standardize early around HL7/FHIR-compatible representations rather than letting every downstream step interpret raw source formats differently. That created a clearer contract between ingestion, extraction, and registry-facing outputs.

Another was to use LLM-assisted extraction selectively. I did not treat LLMs as a universal parsing layer. They were most valuable where clinical text contained useful information that was difficult to capture through deterministic rules alone. By constraining where they sat in the pipeline, it became easier to reason about reliability and preserve a stable surrounding system.

I also favored pipeline designs that made intermediate states legible. In a clinical setting, traceability matters. If an extracted field looked wrong, the path back to the source, mapping logic, and transformation layer needed to stay understandable.

Reliability and Evaluation

Reliability here was not a single benchmark; it was a systems property.

I focused on pipeline behavior that could support trustworthy downstream use: schema consistency, validation around transformed outputs, and extraction workflows that could be reviewed and iterated when failure modes appeared. The goal was not just to maximize extraction coverage, but to make the overall workflow dependable in real registry operations.

That required thinking beyond model quality alone. A strong extraction component inside a weak normalization pipeline still produces brittle results. The system had to be coherent end to end.

Outcome

The result was a stronger clinical data foundation for registry and analytics workflows: more standardized inputs, more usable structured outputs, and less repeated downstream cleanup. In practice, the value was architectural as much as algorithmic. Standardizing the data contract early made later analytics and extraction work easier to trust and easier to evolve.

Because the work was tied to private operational systems, the public signal here is intentionally about workflow ownership and technical decision quality rather than confidential metrics. The important thing I can show honestly is the system shape: I owned the normalization boundary, the extraction integration points, and the reliability tradeoffs that made the pipeline usable downstream.

The work reinforced a pattern that still shapes how I build AI systems: some of the highest-leverage improvements come from better workflow design, cleaner data contracts, and more disciplined system boundaries rather than from model complexity alone.

What I Owned

I owned the design and implementation of end-to-end ETL and NLP pipelines for clinical data workflows, including normalization strategy, schema alignment, extraction integration, validation logic, and the practical shape of how outputs became usable downstream.

Reflection

This project is a good representation of how I like to work: careful about interfaces, skeptical of unnecessary complexity, and focused on making advanced methods useful inside real operating constraints. In applied AI, credibility comes from systems that hold together under messy conditions. That is the kind of work I find most meaningful.