Por qué los equipos de pharma intelligence necesitan datos de salud públicos
Si trabajas en market access, payer analytics o health-tech, ya sabes que los datos públicos de salud son la base de cualquier estrategia de precios competitiva, monitoreo de ensayos clínicos o validación de directorios de proveedores. El problema: acceder a esos datos a escala no es trivial. Sitios como GoodRx, bases de datos del FDA o portales de transparencia de precios estatales implementan protecciones anti-bot agresivas, variaciones geográficas de precios y estructuras de datos inconsistentes.
Este artículo te muestra cómo construir un pipeline de pharma intelligence scraping que respete estrictamente los límites de HIPAA, se limite a datos públicos y use healthcare data proxies para acceder de forma fiable a fuentes como GoodRx, ClinicalTrials.gov, CMS Open Data y NPPES.
Regla inviolable: Este guía cubre exclusivamente datos públicamente disponibles. Nunca scrapees datos identificables de pacientes, registros médicos electrónicos (EHR) ni información protegida bajo HIPAA. Si tienes duda sobre si un dato está cubierto por HIPAA, no lo scrapees.
Fuentes de datos de salud públicas: panorama completo
Las fuentes públicas más relevantes para equipos de inteligencia farmacéutica y analítica de pagadores se dividen en varias categorías:
Precios de medicamentos y transparencia
- GoodRx — Precios de venta al público por farmacia y código postal. Anti-bot agresivo; requiere proxies residenciales rotativos.
- CMS Open Data — Datos de reembolso de Medicare Part D, pagos a proveedores (Open Payments), utilización de dispositivos médicos.
- Portales estatales de transparencia — Varias legislaciones estatales (ej. California, Colorado, Texas) exigen la publicación de precios hospitalarios. Formatos y protecciones varían enormemente.
Bases regulatorias y de ensayos clínicos
- FDA Drugs@FDA — Aprobaciones, etiquetado, patentes y exclusividades. API pública disponible pero con límites de rate.
- NIH ClinicalTrials.gov — Registro de ensayos clínicos con estados, criterios de elegibilidad, resultados. API v2 disponible.
- FDA FAERS — Eventos adversos reportados (datos desidentificados, públicos).
Directorios de proveedores
- NPPES NPI Registry — Directorio público de proveedores con NPI, especialidad, dirección. Descarga completa y API disponibles.
Investigación abierta
- PubMed / PubMed Central — Literatura biomédica abierta con API.
| Fuente | Tipo de dato | Acceso | Dificultad de scraping | ¿Proxies residenciales? |
|---|---|---|---|---|
| GoodRx | Precios de medicamentos | Web (sin API pública) | Alta — anti-bot agresivo | Sí |
| CMS Open Data | Reembolso, pagos | Descarga + API | Baja-Media | Opcional |
| FDA Drugs@FDA | Aprobaciones, etiquetado | API pública | Baja | No (rate limiting) |
| ClinicalTrials.gov | Ensayos clínicos | API v2 | Baja | No |
| NPPES NPI | Directorio de proveedores | Descarga + API | Baja | No |
| Portales estatales | Precios hospitalarios | Web variable | Alta — protecciones diversas | Sí (varía por estado) |
Por qué necesitas proxies residenciales para scrapear precios de medicamentos
GoodRx y varios portales estatales de transparencia de precios implementan protecciones anti-bot particularmente agresivas:
- GoodRx usa Cloudflare con challenges JavaScript, fingerprinting de navegador y rate limiting por IP. Las IPs de datacenter son bloqueadas en minutos. Necesitas IPs residenciales que roten por solicitud para mantener el acceso.
- Portales estatales como los de California (Chime) o Colorado tienen WAFs que detectan patrones de scraping automatizado. Las IPs residenciales locales (del mismo estado) son menos sospechosas.
- Variación geográfica de precios — Los precios de GoodRx varían por código postal. Para scrapear drug prices de múltiples regiones, necesitas proxies residenciales con geo-targeting a nivel de ciudad o estado.
Los proxies de datacenter funcionan bien para APIs abiertas (FDA, ClinicalTrials.gov, NPPES) donde solo necesitas gestionar rate limits. Pero para cualquier sitio que sirva precios de medicamentos vía web rendering, los proxies residenciales son obligatorios.
Geo-targeting: los precios de medicamentos varían por estado y código postal
Este es uno de los aspectos más críticos para equipos de market access. Un medicamento como Ozempic puede tener precios significativamente diferentes en Nueva York vs. Texas vs. California. Si scrareas GoodRx desde una sola ubicación, obtienes precios distorsionados para una sola región.
Con ProxyHat, puedes geo-targetear tus solicitudes a nivel de país, estado e incluso ciudad:
# Precios en Nueva York
http://user-country-US-state-NY:PASSWORD@gate.proxyhat.com:8080
# Precios en California
http://user-country-US-state-CA:PASSWORD@gate.proxyhat.com:8080
# Precios en Texas, Houston
http://user-country-US-state-TX-city-houston:PASSWORD@gate.proxyhat.com:8080Esto te permite construir un mapa de precios real por región, esencial para benchmarking de market access y negociaciones con pagadores.
Arquitectura: de scraping a data warehouse
Un pipeline de pharma intelligence scraping robusto tiene estas capas:
1. Capa de ingesta (scraping)
Módulos separados por fuente, cada uno con su configuración de proxy:
- GoodRx scraper — Proxies residenciales rotativos con geo-targeting, headless browser (Playwright/Puppeteer) para manejar JS challenges, sesiones sticky para completar flujos de página.
- FDA / ClinicalTrials.gov / NPPES — Proxies de datacenter o sin proxy, usando las APIs públicas con rate limiting respetuoso.
- Portales estatales — Proxies residenciales con geo-targeting al estado correspondiente.
2. Capa de normalización
Los datos de cada fuente tienen formatos distintos. Necesitas normalizar:
- Identificadores de medicamentos — Mapear nombres comerciales a NDC (National Drug Code), RxCUI, y UNII.
- Ubicaciones — Estandarizar estados, códigos postales, FIPS codes.
- Fechas — Unificar formatos de fecha de aprobación, fechas de ensayo, etc.
- Proveedores — Normalizar NPI, especialidades, afiliaciones institucionales.
3. Capa ETL
Transformar y cargar en tu data warehouse (BigQuery, Snowflake, Redshift) con:
- Deduplicación por fuente y fecha de ingesta.
- Validación de integridad (NDCs válidos, NPIs activos, rangos de precios razonables).
- Particionado por fecha y fuente para consultas eficientes.
Ejemplo de código: scraping de GoodRx con geo-targeting
import requests
from datetime import datetime, timedelta
PROXY_BASE = "http://user-country-US-state-{state}:PASSWORD@gate.proxyhat.com:8080"
STATES = ["NY", "CA", "TX", "FL", "IL", "PA", "OH", "GA", "NC", "MI"]
DRUGS = ["ozempic", "mounjaro", "trulicity", "humira", "stelara"]
def fetch_goodrx_price(drug: str, state: str) -> dict:
proxy_url = PROXY_BASE.format(state=state)
proxies = {"http": proxy_url, "https": proxy_url}
# GoodRx requiere sesión sticky para completar JS challenges
session = requests.Session()
session.proxies = proxies
url = f"https://www.goodrx.com/{drug}"
headers = {
"User-Agent": (
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/125.0.0.0 Safari/537.36"
),
"Accept": "text/html,application/xhtml+xml",
"Accept-Language": "en-US,en;q=0.9",
}
resp = session.get(url, headers=headers, timeout=30)
resp.raise_for_status()
# NOTA: En producción, usa Playwright/Puppeteer para renderizar JS.
# Aquí se muestra la configuración de proxy con geo-targeting.
return {
"drug": drug,
"state": state,
"scraped_at": datetime.utcnow().isoformat(),
"status_code": resp.status_code,
"source": "goodrx",
}
# Ejecutar para múltiples estados y medicamentos
for state in STATES:
for drug in DRUGS:
result = fetch_goodrx_price(drug, state)
print(result)En producción, reemplazarías requests con Playwright para manejar los challenges de JavaScript de GoodRx. La configuración de proxy con geo-targeting permanece igual — solo necesitas configurar el proxy del navegador.
Ejemplo de consulta: ClinicalTrials.gov API
Para fuentes con API pública, no necesitas proxies residenciales, pero sí gestión de rate limits:
import requests
import time
BASE_URL = "https://clinicaltrials.gov/api/v2/studies"
def search_trials(condition: str, page_token: str = None) -> dict:
params = {
"query.cond": condition,
"filter.overallStatus": "RECRUITING",
"fields": "NCTId,BriefTitle,Phase,StartDate,OrgStudyId",
"pageSize": 50,
}
if page_token:
params["pageToken"] = page_token
resp = requests.get(BASE_URL, params=params, timeout=30)
resp.raise_for_status()
return resp.json()
# Monitorear ensayos en reclutamiento para una condición
data = search_trials("non-alcoholic steatohepatitis")
for study in data.get("studies", []):
protocol = study.get("protocolSection", {})
identification = protocol.get("identificationModule", {})
print(f"{identification.get('nctId')} — {identification.get('briefTitle')}")
# Respetar rate limits — no más de 5 req/s
time.sleep(0.25)Cumplimiento: límites de HIPAA y regulaciones estatales
Este es el aspecto más crítico de cualquier operación de scraping de datos de salud. Un error aquí puede tener consecuencias legales severas.
HIPAA: lo que NO debes scrapear
HIPAA (Health Insurance Portability and Accountability Act) protege la Información de Salud Protegida (PHI). La regla es simple:
Solo scrapee datos que cualquier persona podría encontrar en un sitio web público sin autenticación especial. Si el dato está asociado a un individuo identificable y proviene de un sistema médico, está protegido por HIPAA.
Ejemplos de datos que NUNCA debes scrapear:
- Registros médicos electrónicos (EHR/EMR) de cualquier sistema.
- Datos de reclamos (claims) de aseguradoras que contengan identificadores de pacientes.
- Resultados de laboratorio asociados a individuos.
- Prescripciones vinculadas a pacientes específicos.
- Cualquier dato de portales que requieran credenciales de pacientes o proveedores.
Ejemplos de datos públicos que SÍ puedes scrapear:
- Precios de medicamentos publicados en GoodRx, Amazon Pharmacy o sitios de transparencia estatal.
- Información de aprobación del FDA (etiquetado, patentes, exclusividades).
- Registros de ensayos clínicos en ClinicalTrials.gov (datos de contacto del investigador son públicos).
- Datos de reembolso agregados de CMS (Medicare Part D, Open Payments).
- Directorio NPPES con NPI, especialidad y dirección de práctica.
Regulaciones estatales de datos de salud
Varios estados tienen regulaciones adicionales que van más allá de HIPAA:
- California (CMIA) — California Confidentiality of Medical Information Act protege información médica incluso de fuentes no cubiertas por HIPAA. No scrapees datos de salud identificables de fuentes californianas, incluso si son técnicamente públicas.
- Nueva York (SHIELD Act) — Requiere salvaguardas para datos privados. Aplica si almacenas datos de residentes de NY.
- Washington (My Health My Data Act) — Protege datos de salud no HIPAA con requisitos de consentimiento. Extremadamente amplio; consulta con legal antes de scrapear cualquier dato de salud de Washington.
Recomendación: Mantén un registro de qué datos scraeas, de qué fuente, y qué regulación aplica. Documenta tu análisis de cumplimiento para cada fuente antes de iniciar el scraping.
Buenas prácticas de cumplimiento
- Respeta robots.txt — Verifica antes de scrapear. Si un directorio está bloqueado, evalúa si hay una API alternativa.
- Rate limiting razonable — No satures servidores. Usa delays entre solicitudes y respeta los límites de la API.
- No evadas autenticación — Si un sitio requiere login para acceder a datos, esos datos probablemente no son públicos en el sentido legal.
- Revisión legal periódica — Las regulaciones cambian. Revisa tu compliance framework cada trimestre.
- Minimización de datos — Solo recopila lo que necesitas. No almacenes datos «por si acaso».
Casos de uso: de datos públicos a inteligencia accionable
Benchmarking de precios para market access
Un equipo de market access necesita comparar los precios de su portafolio contra los competidores en múltiples regiones. Scrapear precios de GoodRx, Amazon Pharmacy y portales estatales con geo-targeting permite:
- Identificar variaciones regionales de precios que afectan negociaciones con PBMs.
- Detectar tendencias de precios a lo largo del tiempo (¿están subiendo los descuentos de la competencia?).
- Construir modelos de precios predictivos para lanzamientos de nuevos medicamentos.
Monitoreo del landscape de ensayos clínicos
Consultar ClinicalTrials.gov y el FDA de forma periódica permite:
- Detectar nuevos ensayos de la competencia en tu área terapéutica.
- Monitorear cambios de estado de ensayos (de reclutamiento a completado).
- Identificar investigadores clave (KOLs) por área terapéutica basándose en los datos de contacto públicos de los ensayos.
Validación de directorios de proveedores
Los directorios de proveedores (NPPES, directorios de planes de salud) son notoriamente inexactos. Scrapear y cruzar NPPES con otros directorios permite:
- Detectar NPIs inactivos o con información desactualizada.
- Verificar que los proveedores en tu red siguen activos y en la especialidad declarada.
- Identificar gaps de cobertura geográfica donde no hay proveedores de cierta especialidad.
Elección de proxy: residenciales vs. datacenter para datos de salud
| Criterio | Residenciales | Datacenter |
|---|---|---|
| GoodRx / sitios anti-bot | ✅ Necesario | ❌ Bloqueado rápido |
| Portales estatales con WAF | ✅ Recomendado | ⚠️ Funciona a veces |
| FDA / ClinicalTrials.gov API | ⚠️ Innecesario | ✅ Suficiente |
| NPPES / CMS descargas | ⚠️ Innecesario | ✅ Suficiente |
| Geo-targeting por estado | ✅ Disponible | ❌ No aplica |
| Costo por GB | Mayor | Menor |
| Velocidad | Menor | Mayor |
La estrategia óptima es un enfoque híbrido: usa proxies residenciales solo para las fuentes que los necesitan (GoodRx, portales estatales) y proxies de datacenter o conexión directa para APIs abiertas.
Estrategia de rotación de IPs para scraping farmacéutico
Para GoodRx y sitios similares, la estrategia de rotación importa:
- Rotación por solicitud — Ideal para scrapear múltiples medicamentos en múltiples ubicaciones. Cada request va desde una IP residencial diferente, minimizando la detección.
- Sesiones sticky — Necesarias cuando el sitio requiere completar un flujo multi-página (ej. seleccionar farmacia, ver cupón). Mantienes la misma IP por 10-30 minutos.
Con ProxyHat, controlas esto mediante el parámetro de sesión en el username:
# Rotación automática (por solicitud)
http://user-country-US-state-CA:PASSWORD@gate.proxyhat.com:8080
# Sesión sticky (misma IP por hasta 30 min)
http://user-country-US-state-CA-session-mkt-access-01:PASSWORD@gate.proxyhat.com:8080Key Takeaways
- Solo datos públicos. Nunca scrapees datos protegidos por HIPAA o identificables de pacientes. Si duda, no lo haga.
- Proxies residenciales para sitios anti-bot. GoodRx y portales estatales requieren IPs residenciales con geo-targeting. APIs abiertas funcionan con datacenter.
- Geo-targeting es esencial. Los precios de medicamentos varían por estado y código postal. Scraea desde múltiples ubicaciones para datos representativos.
- Arquitectura por capas. Ingesta → normalización → ETL → warehouse. Cada fuente tiene su módulo con su configuración de proxy.
- Cumplimiento continuo. Regulaciones estatales como CMIA (CA) y My Health My Data (WA) van más allá de HIPAA. Revisa con legal cada trimestre.
- Enfoque híbrido en proxies. Residenciales para scraping web con anti-bot; datacenter o directo para APIs públicas. Optimiza costos.
Próximos pasos
Si estás construyendo un pipeline de pharma intelligence, empieza por:
- Documentar qué fuentes necesitas y clasificarlas por dificultad de acceso (anti-bot vs. API abierta).
- Hacer un análisis de cumplimiento para cada fuente con tu equipo legal.
- Configurar proxies residenciales con geo-targeting para las fuentes que lo necesitan. Puedes empezar probando en los planes de ProxyHat.
- Construir la capa de normalización antes de la de ingesta — saber cómo vas a unificar los datos te ayuda a diseñar mejor el scraping.
Para más detalles sobre arquitectura de scraping, consulta nuestra guía de mejores prácticas de web scraping y el caso de uso de web scraping.






