David Matthew Quintana

The Problem

El Problema

A decommissioned Clinical Trial Management System left ~9,925 documents in inconsistently named folders, plus a separate 6,830-record patient database — with no archive structure. Everything had to be understood, cleaned, and validated before migration, without ever exposing patient data to an external AI or cloud service.

Un Sistema de Gestión de Ensayos Clínicos desmantelado dejó ~9,925 documentos en carpetas con nombres inconsistentes, más una base de datos de 6,830 pacientes — sin estructura de archivo. Todo debía entenderse, limpiarse y validarse antes de migrar, sin exponer nunca datos de pacientes a una IA o nube externa.

The Action

La Acción

I built a 10-stage local Python ETL pipeline: capture raw structure, crawl and classify every document, build a patient roster, clean the patient database, cross-validate documents against patients, generate a SharePoint build plan, and tag by study and deviation. The validation stage cross-checks each document's extracted patient ID against the real database.

Construí un pipeline ETL local de 10 etapas en Python: capturar la estructura, rastrear y clasificar cada documento, construir un registro de pacientes, limpiar la base de datos, validar los documentos contra los pacientes, generar un plan de SharePoint y etiquetar por estudio y desviación. La etapa de validación coteja el ID extraído de cada documento contra la base de datos real.

Tech Stack

Tecnologías

Python (pandas, openpyxl), Regex, JSON/YAML config, python-docx, SharePoint

Workflow

Flujo de Trabajo

Raw logs + patient DB → Clean & classify → Cross-validate → SharePoint archive

Logs + base de datos → Limpiar y clasificar → Validar → Archivo SharePoint

The Impact

Impacto

• Data integrity: caught 1,791 documents (18%) whose filename patient IDs matched no real patient — before migration, not after.
• Compliance: all processing local; PHI masked in every log; no patient data exposed to AI or cloud.
• Usability: delivered a searchable SharePoint archive with Patient Lookup and Deviation views staff had asked for.

• Integridad de datos: detectó 1,791 documentos (18%) cuyos IDs de nombre no coincidían con ningún paciente real — antes de migrar, no después.
• Cumplimiento: todo el procesamiento local; PHI enmascarado en cada registro; sin exponer datos a IA o nube.
• Usabilidad: un archivo SharePoint consultable con vistas de Búsqueda de Paciente y Desviaciones que el personal pedía.

What This Demonstrates

Lo que esto Demuestra

End-to-end ETL on messy, real-world clinical data — with validation that catches errors before they propagate, compliance built in by design, and a reproducible, documented, schema-driven pipeline.

ETL de extremo a extremo sobre datos clínicos reales y desordenados — con validación que detecta errores antes de que se propaguen, cumplimiento por diseño y un pipeline reproducible, documentado y guiado por esquema.

The Problem

El Problema

Language barriers during intake lead to "dirty data" and incomplete clinical histories. Standardizing this data into a format EHRs can actually read (FHIR) is often a manual, error-prone hurdle.

Las barreras lingüísticas en la admisión provocan historiales clínicos incompletos y errores demográficos, mientras que la entrada manual de datos crea agotamiento administrativo y silos de información.

The Action

La Acción

I engineered a full‑stack application with an i18n‑enabled frontend (English/Spanish). The system captures Patient‑Generated Health Data (PGHD) and uses a FastAPI backend to map raw inputs into validated HL7 FHIR R4 Patient and Observation resources.

Un sistema full-stack con alternancia inglés/español en tiempo real. El frontend captura Datos de Salud Generados por Pacientes (PGHD), que un backend FastAPI mapea a recursos HL7 FHIR R4 de Paciente y Observación para interoperabilidad nativa con EHR.

Tech Stack

Tecnologías

Python (FastAPI), JavaScript (ES6+), Pydantic Models, HL7 FHIR R4, JSON Schema Validation

Workflow

Flujo de Trabajo

Patient → Bilingual Intake Form → FastAPI Validation → FHIR Mapping → JSON Output → EHR Integration

Paciente → Formulario Bilingüe → Validación FastAPI → Mapeo FHIR → Salida JSON → Integración EHR

The Impact

Impacto Clínico

• Interoperability: Produces production‑ready JSON payloads for native EHR integration.
• Health Equity: Empowers Spanish‑speaking patients to provide history in their primary language without data loss.
• Data Integrity: Implements strict Pydantic schema validation to eliminate malformed clinical data at the source.

• Interoperabilidad: Genera JSON compatible con FHIR en el punto de atención
• Equidad en Salud: Permite a pacientes hispanohablantes proporcionar su historial en su idioma principal
• Flujo de Trabajo: Reduce errores administrativos y tiempo de reingreso de datos

Security & Privacy

Seguridad y Privacidad

Stateless architecture; no PHI stored.

Arquitectura sin estado; no se almacena PHI.

Representative File Structure

Estructura de Archivos Representativa

bilingual-patient-intake-fhir/
│── .gitignore
│── LICENSE
│── README.md
│── index.html
│
├── backend/
│   ├── app.py           # FastAPI logic & FHIR mapping# Lógica FastAPI y mapeo FHIR
│   ├── requirements.txt
│   └── __pycache__/
│
└── static/
    ├── css/
    └── js/              # i18n and frontend validation# i18n y validación frontend

What This Demonstrates

Lo que esto Demuestra

Applied evidence of clinical data‑integrity engineering — enforcing HL7 FHIR R4 conformance, validating patient‑generated data at the source, and producing interoperable, audit‑ready records under a privacy‑by‑design (no‑PHI) architecture.

Evidencia aplicada de ingeniería de integridad de datos clínicos — conformidad con HL7 FHIR R4, validación de los datos del paciente en el origen y generación de registros interoperables y listos para auditoría bajo una arquitectura centrada en la privacidad (sin PHI).

The Problem

El Problema

Legacy HL7 v2.x messages are "black boxes" for many public health teams, requiring manual interpretation during time‑sensitive outbreaks.

Los mensajes heredados HL7 v2.x son "cajas negras" para muchos equipos de salud pública, requiriendo interpretación manual durante brotes sensibles al tiempo.

The Action

La Acción

Built a specialized parsing engine to process ORU (Observation Result) messages. I utilized Regex‑based extraction and hl7apy to isolate PID and OBX segments, then integrated a LOINC dictionary to validate test codes and flag abnormal findings.

Un motor de análisis especializado para mensajes ORU (Resultados de Observación). Extrae segmentos PID y OBX, valida códigos LOINC y marca hallazgos anormales para enfermedades infecciosas de alta prioridad.

Tech Stack

Tecnologías

JavaScript (Regex Engine), Python (hl7apy), LOINC Dictionary Integration

Workflow

Flujo de Trabajo

Lab System → HL7 Segments → Regex Extraction → LOINC Validation → Clinical Summary

Sistema de Laboratorio → Segmentos HL7 → Extracción Regex → Validación LOINC → Resumen Clínico

The Impact

Impacto Clínico

• Surveillance: Accelerates the triage of positive lab results for public health reporting.
• Normalization: Converts non‑standard lab strings into standardized LOINC/SNOMED‑CT terminology.
• Resilience: Includes a synthetic test suite to ensure the parser handles "broken" or edge‑case legacy messages.

• Vigilancia: Acelera el triaje de resultados de laboratorio positivos
• Precisión: Normaliza datos usando terminología LOINC estandarizada
• Robustez: Maneja mensajes malformados con elegancia

Security & Privacy

Seguridad y Privacidad

Processes only synthetic HL7 messages.

Procesa únicamente mensajes HL7 sintéticos.

Representative File Structure

Estructura de Archivos Representativa

hl7-infectious-disease-parser/
│── LICENSE
│── README.md
│── index.html
│── parser.py         # Regex-based extraction & LOINC validation# Extracción Regex y validación LOINC
│── script.js         # UI rendering for clinical summaries# Renderizado UI para resúmenes clínicos
│── style.css
│
└── hl-samples/       # Synthetic test suite# Suite de pruebas sintéticas
    ├── adt_a01.txt
    ├── adt_a03.txt
    ├── broken_oru.txt
    ├── covid_oru.txt
    ├── flu_oru.txt
    └── hiv_oru.txt

What This Demonstrates

Lo que esto Demuestra

Applied evidence of standards‑based normalization and validation — converting legacy HL7 v2.x into LOINC/SNOMED‑CT‑coded records with defensible, testable logic that supports audit‑ready public‑health surveillance reporting.

Evidencia aplicada de normalización y validación basada en estándares — conversión de HL7 v2.x heredado en registros codificados con LOINC/SNOMED‑CT mediante una lógica defendible y verificable que respalda informes de vigilancia de salud pública listos para auditoría.

The Problem

El Problema

Pediatric dosing errors are "Never Events" in clinical safety. Communication gaps with non‑English speaking caregivers significantly increase outpatient medication risks.

Los errores de dosificación pediátrica son eventos centinela de alto riesgo. Las brechas de comunicación con cuidadores hispanohablantes aumentan los riesgos de medicación ambulatoria.

The Action

La Acción

Developed a Clinical Decision Support (CDS) tool with built‑in safety guardrails. I implemented weight‑based dose caps and an 80% maximum‑dose caution threshold. The system uses JSON Localization (L10n) to generate precise, bilingual instructions for caregivers.

Una herramienta de Soporte a la Decisión Clínica (CDS) que impone límites estrictos basados en peso y genera instrucciones bilingües para los cuidadores.

Tech Stack

Tecnologías

Python (FastAPI), JavaScript (ES6+), Pydantic Models, JSON Localization

Workflow

Flujo de Trabajo

Patient Input → Safety Validation → Dose Calculation → Bilingual Instructions

Entrada del Paciente → Validación de Seguridad → Cálculo de Dosis → Instrucciones Bilingües

The Impact

Impacto Clínico

• Clinical Safety: Rejects physiologically impossible weights and caps doses to prevent sentinel events.
• Caregiver Adherence: Reduces "lost‑in‑translation" errors by providing native‑language instructions for complex liquid dosing.
• Technical Precision: Demonstrates a stateless architecture capable of being embedded into larger clinical workflows.

• Prevención de Eventos Centinela: Rechaza pesos poco realistas y limita dosis
• UI de Seguridad: Implementa un umbral de precaución del 80%
• Seguridad Bilingüe: Reduce la confusión del cuidador

Security & Privacy

Seguridad y Privacidad

Stateless; no PHI stored.

Sin estado; no se almacena PHI.

Representative File Structure

Estructura de Archivos Representativa

bilingual-pediatric-CDS-dosage-calculator/
│── .gitignore
│── LICENSE
│── README.md
│── index.html
│── app.js
│── styles.css
│
├── backend/
│   ├── main.py           # API Entry point# Punto de entrada de API
│   ├── calculations.py   # Safety-critical logic# Lógica crítica de seguridad
│   ├── models.py         # Data validation schemas (Pydantic)# Esquemas de validación (Pydantic)
│   └── requirements.txt
│
├── lang/
│   ├── en.json           # English localization# Localización en Inglés
│   └── es.json           # Spanish localization# Localización en Español
│
└── __pycache__/
    ├── calculations.cpython-313.pyc
    └── models.cpython-313.pyc

What This Demonstrates

Lo que esto Demuestra

Applied evidence of safety‑critical compliance logic — enforcing weight‑based dose caps and caution thresholds as verifiable guardrails, delivered accessibly (WCAG 2.1 AA) and bilingually to protect patient safety across the language barrier.

Evidencia aplicada de lógica de cumplimiento crítica para la seguridad — límites de dosis basados en peso y umbrales de precaución como salvaguardas verificables, entregados de forma accesible (WCAG 2.1 AA) y bilingüe para proteger la seguridad del paciente a través de la barrera del idioma.