dbparser: de bases de datos farmacológicas complejas a flujos reproducibles en R

Las grandes bases de datos farmacológicas son valiosas porque conservan relaciones complejas entre medicamentos, objetivos, vías biológicas, productos, efectos adversos e interacciones. También son difíciles de analizar por esa misma razón. DrugBank se distribuye como XML profundamente anidado; OnSIDES como archivos CSV relacionales; TWOSIDES como datos comprimidos de interacciones. dbparser transforma esas fuentes diferentes en objetos de R consistentes y flujos de integración trazables.

01El problema es estructural, no cosmético

Una base farmacológica no es una hoja de cálculo con demasiadas columnas. Los registros de medicamentos se conectan con objetivos, enzimas, carriers, transporters, vías biológicas, productos, referencias e identificadores externos. Un parser que sólo aplana el archivo puede facilitar su carga y, al mismo tiempo, destruir silenciosamente las relaciones que dan significado a los datos.

Las fuentes tampoco comparten formatos ni identificadores. DrugBank utiliza una jerarquía XML extensa. OnSIDES distribuye tablas CSV relacionadas derivadas de etiquetas de medicamentos. TWOSIDES ofrece una representación comprimida de efectos adversos asociados con pares de medicamentos. Los scripts ad hoc pueden resolver un análisis, pero suelen ocultar supuestos sobre joins, versiones y valores faltantes.

02Un objeto común sin borrar la fuente

dbparser introduce el dvobject, un objeto drugverse implementado como una lista de R con patrones de acceso consistentes. Conserva tablas tidy para el análisis, metadatos sobre la versión de la base y el proceso de parsing, y mapas que describen cómo se relacionan las tablas.

Para una versión de DrugBank, el objeto puede exponer información de medicamentos, sales, productos, referencias y estructuras conectadas de carriers, enzymes, targets y transporters. Cuando se fusionan fuentes, el mismo objeto incorpora componentes anidados y tablas integradas, en lugar de convertirse en una colección de joins sin documentar.

03De parser a motor de integración

La versión actual del paquete utiliza DrugBank como núcleo mecanístico. OnSIDES aporta eventos adversos extraídos de etiquetas de la FDA, mientras TWOSIDES aporta eventos asociados con combinaciones de medicamentos. Esta arquitectura radial reduce la cantidad de equivalencias entre identificadores que deben mantenerse y hace explícita la ruta de integración.

La decisión implica una condición: los flujos con varias bases dependen de los identificadores y equivalencias de DrugBank. Sin embargo, es una condición visible y comprobable, no un supuesto escondido dentro de un notebook de un solo uso.

04La ingeniería de software alrededor del parser

Un paquete de investigación útil necesita más que funciones de parsing que operen correctamente. Requiere una interfaz pública estable, pruebas, documentación, metadatos, ejemplos, versiones identificables y un proceso para revisar cambios. dbparser se distribuye por CRAN, se documenta mediante rOpenSci, se publica con licencia MIT y se mantiene en un repositorio público.

El paquete pasó por revisión por pares en rOpenSci y su artículo de software se publicó en el Journal of Open Source Software en febrero de 2026. Ese registro importa porque hace verificables las afirmaciones de calidad: cualquier persona puede consultar el repositorio, la revisión, la versión archivada, la documentación y el seguimiento de incidencias.

05Un flujo compacto y reproducible

El código siguiente muestra la arquitectura sin esconderla detrás de una interfaz gráfica. Cada fuente se procesa de forma independiente. Después, los objetos resultantes se fusionan mediante operaciones explícitas y encadenables. El código se conserva exactamente como aparece en la documentación del paquete.

library(dbparser)
library(dplyr)

drugbank_db <- parseDrugBank("data/drugbank.xml")
onsides_db  <- parseOnSIDES("data/onsides/")
twosides_db <- parseTWOSIDES("data/TWOSIDES.csv.gz")

final_db <- drugbank_db %>%
  merge_drugbank_onsides(onsides_db) %>%
  merge_drugbank_twosides(twosides_db)

head(final_db$integrated_data$drug_drug_interactions)

06De proyecto estudiantil a infraestructura de investigación

CRAN registra la primera versión de dbparser en diciembre de 2018. El archivo público muestra después una secuencia de versiones mantenidas, no una publicación aislada. Para la versión 2.2.1, publicada en enero de 2026, el paquete ya había superado el procesamiento exclusivo de DrugBank y permitía flujos integrados de farmacovigilancia con tres fuentes.

La documentación del proyecto identifica más de diez publicaciones revisadas por pares en áreas como reposicionamiento de medicamentos, biomarcadores, modelado de vías biológicas y análisis de ensayos clínicos. La historia más sólida no es sólo que un estudiante escribió un parser, sino que el trabajo resistió el uso por otros equipos, la evolución de las bases fuente, la revisión del paquete y el mantenimiento a largo plazo.

07El egresado detrás del proyecto de código abierto

Mohammed Ali es egresado de DSTI, autor y responsable de mantenimiento de dbparser. Ali Ezzat es coautor del paquete y del artículo de JOSS. Su registro público permite revisar el software en varios niveles: la versión estable en CRAN, el manual de referencia, la documentación de rOpenSci, el repositorio fuente, la conversación de revisión y la publicación archivada en JOSS.

Esa apertura forma parte del resultado de ingeniería. Una herramienta de investigación reproducible debe permitir rastrear no sólo el resultado del análisis, sino también la versión del software, la versión de los datos fuente y las decisiones que transformaron una en el otro.

Software, documentación y publicación

Fuentes y nota editorial: Artículo elaborado a partir del antiguo registro de DSTI sobre el proyecto estudiantil, un manuscrito proporcionado y las fuentes actuales de CRAN, rOpenSci, el repositorio y JOSS. Los nombres técnicos, funciones del paquete, código y títulos de publicaciones se conservan exactamente.