Clinical Registry Intelligence

At Carta Healthcare, I built clinical ETL and NLP pipelines and applied LLM-assisted extraction to registry workflows. This retrospective covers my work as a Data Scientist from March 2022 to February 2024, connecting clinical data preparation with information extraction from text.

Engineering Problem

Structured fields and narrative documentation present different processing problems: field mapping and transformation on one side, text interpretation and extraction on the other. Clinical registry workflows bring those concerns together.

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

Processing Boundaries

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

ETL and NLP served different purposes: preparing clinical inputs for downstream processing, and extracting information from text. A useful way to reason about the workflow is to separate ingestion and transformation from extraction and downstream consumption.

LLM-assisted extraction addressed information in clinical narrative. The engineering question was how to connect that extraction step with the surrounding data workflow while keeping the processing boundaries understandable.

Decisions and Trade-offs

My professional record includes clinical ETL/NLP, HL7/FHIR conversion, and LLM-assisted registry extraction. The figure and the following questions organize that public description into an engineering discussion.

Engineering considerations at the public workflow’s abstraction level.

Boundary	Reasoning and evaluation lens
Mapping	Separate source mapping and representation choices from extraction logic. Trade-off: a shared representation still requires attention to source-specific conventions. Review schema consistency and missing fields.
Extraction	Distinguish deterministic processing from NLP and selective LLM-assisted extraction. Trade-off: language methods add evaluation questions beyond field mapping. Review extraction errors and the source evidence for each field.
Outputs	Make the relationship between source information and structured output discussable. Evaluation lens: can a field be traced through its mapping and transformation path? This is a review question, not a published audit result.

Contribution and Public Scope

My contribution was clinical ETL/NLP development and LLM-assisted registry extraction within my Data Scientist role. The public narrative describes those responsibilities and a conceptual workflow; implementation details, patient data, schemas, prompts, and operational examples remain confidential.

Public material does not include clinical benchmarks or operational reports. Accordingly, this retrospective does not quantify performance, establish HL7/FHIR conformance, or attribute clinical or organizational outcomes.

Reflection

The work reinforced an approach that still shapes how I build: make interfaces explicit, separate processing concerns, and evaluate the workflow around the model as carefully as the model itself.