Datos de producto regulados: cómo trabajo con atributos que no admiten error en un catálogo farmacéutico

En un catálogo farmacéutico hay datos que no puedo completar por aproximación, inferir porque “parecen correctos” ni modificar solamente para que queden más prolijos. Cuando la información está regulada, cambia mi manera de validar cada atributo: además del valor necesito saber de dónde salió, para qué mercado aplica, qué versión estoy mirando y quién puede aprobarla antes de que llegue a un canal.

Hay una costumbre que me sirve muchísimo cuando trabajo con información de producto: si encuentro algo raro, lo miro de cerca. Comparo, busco patrones, trato de entender de dónde vino y recién después decido qué hacer. Con datos regulados esa costumbre deja de ser solamente una forma personal de trabajar y se convierte en una necesidad, porque no todos los errores de catálogo pesan lo mismo.

Puedo encontrar un color escrito de dos maneras y tener un problema de consistencia. Puedo encontrar una descripción comercial con una errata y necesitar una corrección. Pero si estoy frente a un principio activo, una concentración, una forma farmacéutica, una condición de prescripción o determinada información autorizada para un medicamento, no puedo intervenir con el mismo grado de libertad. Ahí ya no alcanza con preguntarme si el dato está completo, bien escrito o correctamente formateado. También necesito saber si corresponde a la fuente adecuada, si sigue vigente y si aplica exactamente al producto, presentación y mercado que estoy modelando.

En un catálogo regulado, “completo” no significa solamente que el campo tenga un valor. Significa que tiene el valor correcto, proveniente de la fuente correcta y dentro del contexto correcto.

¿Qué cambia cuando un atributo está regulado?

Para mí, el cambio más importante es que dejo de pensar el dato únicamente por su contenido y empiezo a mirarlo también por su procedencia, vigencia y autoridad. En un catálogo convencional puedo definir que “Material” será una lista controlada, establecer qué opciones acepta y normalizar valores siguiendo un criterio acordado con el equipo. Cuando la información está regulada, esa autonomía tiene un límite mucho más claro.

Cuando la información está regulada, esa autonomía tiene un límite mucho más claro. El contenido puede estar determinado por un registro sanitario, una ficha técnica autorizada, un prospecto, un etiquetado aprobado u otra fuente oficial. Mi trabajo como analista PIM no consiste en reinterpretar esa información para que encaje mejor en el modelo, sino en construir un modelo capaz de preservarla, identificarla y distribuirla sin alterar su significado.

Eso cambia también las preguntas que hago. Ya no me alcanza con “¿este campo está completo?”. Necesito agregar “¿de dónde salió?”, “¿para qué presentación aplica?”, “¿para qué mercado?”, “¿cuándo fue validado?” y, sobre todo, “¿quién tiene autoridad para decidir que este valor es correcto?”.

Parece una diferencia administrativa, pero no lo es. Cambia bastante el diseño del proceso.

Antes de validar el valor, necesito validar la fuente

Si me dan tres archivos con información distinta para el mismo medicamento, mi primera reacción no debería ser elegir el que parece más completo.

Tampoco el más nuevo por nombre de archivo ni el que está en una carpeta llamada FINAL_FINAL_OK.

Sí, todos vimos alguna.

Lo primero que necesito entender es qué representa cada fuente y qué autoridad tiene sobre cada dato. Un valor tomado de una fuente regulatoria oficial no puede pesar igual que otro copiado de una planilla histórica cuyo origen ya nadie puede reconstruir. Y aunque ambos coincidan hoy, esa diferencia sigue siendo importante porque mañana puedo necesitar validar una actualización o entender por qué se tomó determinada decisión.

Esto resulta bastante visible cuando uno mira cómo publican la información las propias autoridades.

En México, el visor de COFEPRIS permite consultar distintos campos vinculados con los registros sanitarios de medicamentos, entre ellos estado del registro, denominaciones, principio activo, titular, fabricante, vida útil e indicación terapéutica; además, la propia autoridad lo presenta como una plataforma de actualización continua.

En España, CIMA reúne información y documentación oficial de los medicamentos autorizados, incluidas fichas técnicas, prospectos, condiciones de prescripción y modificaciones posteriores.

Desde mi lugar, eso se traduce en algo bastante simple: el linaje del dato también es parte de la calidad del dato. Si no puedo reconstruir de dónde salió un valor crítico, ya tengo un problema aunque visualmente ese valor parezca perfecto.

¿Todos los datos farmacéuticos pertenecen a la misma ficha?

No necesariamente, y este es uno de los puntos donde me parece fácil construir una ficha enorme que mezcla cosas distintas solamente porque todas están relacionadas con “el medicamento”.

Producto, presentación, registro, lote y unidad trazable no son necesariamente la misma entidad. Si no hago esa separación conceptual desde el principio, después aparecen campos que no sé dónde mantener, datos que cambian con frecuencias diferentes y valores históricos que terminan pisándose entre sí.

Un principio activo o una forma farmacéutica describen el producto desde una determinada capa. Un número de lote y una fecha de vencimiento pertenecen a otra granularidad. La identificación unívoca de una unidad agrega todavía otro nivel. ANMAT, por ejemplo, establece dentro de su Sistema Nacional de Trazabilidad el uso de GTIN y número de serie, y contempla también lote y vencimiento en determinados soportes de identificación.

Eso no significa que todos esos datos tengan que terminar como atributos estáticos del producto maestro. Al contrario: me obliga a hacer una de las preguntas que más repito cuando trabajo con modelos de datos: ¿qué estoy describiendo exactamente? Si no puedo responderla con claridad, todavía no estoy lista para crear el atributo.

El hecho de que dos datos hablen del mismo medicamento no significa que pertenezcan a la misma entidad ni que tengan el mismo ciclo de vida.

¿Qué hago cuando la información regulada cambia?

Este es uno de los puntos que más me interesan porque rompe otra idea bastante frecuente: que, una vez validado un dato, el trabajo terminó. Con información regulada, la respuesta es claramente no.

Una ficha técnica puede actualizarse. Un prospecto puede incorporar nueva información. Puede cambiar una condición de prescripción o aparecer una modificación relevante en la información de seguridad. La AEMPS publica este tipo de actualizaciones y remite a CIMA para consultar las versiones vigentes de fichas técnicas y prospectos.

Entonces aparece una dimensión que en otros catálogos puede quedar más escondida: la vigencia. No necesito saber solamente si el dato fue correcto alguna vez. Necesito saber si sigue siendo la versión que corresponde utilizar hoy.

Eso me lleva a pensar en fechas de revisión, estados, versiones, fuentes y responsables. También me obliga a preguntarme qué hago con el valor anterior. ¿Lo sobrescribo? ¿Necesito conservar historial? ¿Desde qué momento aplica el cambio? ¿Impacta a todas las presentaciones? ¿A todos los mercados? Ese tipo de preguntas no se resuelve cambiando una celda. Requiere proceso.

¿Qué pasa cuando el mismo catálogo opera en varios países?

Un catálogo multipaís me obliga a revisar otra suposición bastante cómoda: que existe una ficha maestra y después solamente tengo que traducirla.

Con información regulada no funciona así.

Argentina, México y España tienen autoridades, registros, fuentes y mecanismos propios. Incluso cuando estamos hablando conceptualmente del mismo medicamento, no puedo asumir que un campo regulatorio se replica de un mercado a otro porque el texto sea parecido.

COFEPRIS mantiene en México información sobre registros sanitarios y sus estados, incluidas modificaciones y prórrogas.

AEMPS mantiene en España la información oficial de medicamentos autorizados y sus documentos mediante CIMA.

ANMAT, por su parte, administra sus propios registros y mecanismos de trazabilidad para Argentina.

Eso obliga a pensar determinados atributos con alcance por mercado y, en algunos casos, con fuentes o procesos de aprobación independientes. Hay una secuencia que me sirve para no mezclar estas cosas: traducir no es localizar, localizar no es validar y validar no es autorizar.

Puedo traducir perfectamente un texto que no corresponde publicar en ese país. Puedo adaptar una terminología y seguir trabajando con una versión obsoleta. Puedo comprobar que un campo coincide con una fuente y aun así no ser yo la persona que tiene autoridad para aprobar su uso. Separar esas acciones evita bastantes confusiones.

Centralizar la gestión de un catálogo multipaís no significa borrar las diferencias regulatorias entre mercados. Significa poder administrarlas sin perder control sobre cuál aplica en cada caso.

Mi impulso de correctora también tiene que saber cuándo frenarse

Esta parte me toca bastante de cerca porque vengo del mundo de la edición y la corrección. Veo una inconsistencia y quiero entenderla. Veo un error ortográfico y mi cabeza ya lo corrigió. Veo dos maneras distintas de escribir lo mismo y enseguida quiero descubrir cuál debería quedar.

En datos de producto eso suele ser útil. Trabajo mucho con normalización, vocabularios, reglas de estilo y consistencia. Pero cuando estoy frente a contenido regulado tengo que agregar un freno.

Si detecto algo que parece una errata dentro de una información cuya redacción responde a una fuente autorizada, no puedo “mejorarla” porque gramaticalmente me gusta más otra opción. Primero necesito verificar si realmente estoy mirando un error, si existe una versión posterior, si hubo una transcripción incorrecta o si ese contenido simplemente debe mantenerse como fue autorizado.

La acción puede parecer mínima —a veces consiste únicamente en no tocar todavía una celda—, pero el criterio cambia por completo. Corregir no siempre significa modificar. A veces significa detectar, documentar, escalar y esperar una validación.

Y sí, para una persona que disfruta arreglando cosas, aprender a no arreglarlas por cuenta propia también es parte del trabajo.

¿Cómo adapto las validaciones cuando un dato no admite error?

Cuando un atributo es crítico, intento que la calidad no dependa únicamente de que alguien recuerde revisarlo antes de publicar. Si ya sabemos que determinado dato necesita cumplir una condición, prefiero incorporar esa condición al proceso.

Eso puede traducirse en campos obligatorios por mercado, formatos restringidos, vocabularios controlados, relaciones entre atributos, estados de aprobación, fechas de revisión o bloqueos que impidan avanzar si falta información crítica. En otros casos puede ser necesario registrar también la fuente o el responsable de la última validación.

No siempre hace falta convertir cada campo en un trámite de diez pasos. Sería bastante poco práctico y terminaríamos construyendo un sistema que nadie quiere usar. La clave está en la criticidad del dato.

Si una descripción comercial opcional está incompleta, quizás el producto pueda continuar por determinado flujo y enriquecerse más adelante. Si falta un dato imprescindible para la publicación en ese mercado o el valor todavía no fue validado por quien corresponde, el comportamiento debería ser otro.

Acá la completitud deja de ser una métrica plana. Un producto puede tener casi todos sus campos cargados y seguir sin estar listo si lo que falta es justamente información crítica. Esa distinción ya aparece en el trabajo habitual de diagnóstico de calidad de datos; en un contexto regulado, simplemente adquiere mucho más peso. El propio enfoque editorial de Belén sobre diagnóstico separa completitud, exactitud, validez, consistencia y vigencia precisamente porque un dato presente no es necesariamente un dato confiable.

Una validación también necesita decir quién decide

Hay otra pregunta que aparece bastante rápido cuando diseño este tipo de procesos: si dos fuentes no coinciden, ¿quién resuelve el conflicto?

La respuesta no debería ser “la persona que estaba cargando el PIM ese día”, por más experiencia que tenga.

En información regulada necesito responsabilidades claras. El analista puede detectar la inconsistencia, preparar la comparación, identificar qué productos están afectados y evitar que un dato dudoso siga avanzando. Pero la definición de cuál es el contenido regulatoriamente válido tiene que quedar en manos del área o responsable correspondiente.

Esta separación no disminuye mi responsabilidad; la hace más precisa. Mi trabajo está en construir el circuito para que el dato correcto llegue desde quien puede validarlo hasta los lugares donde tiene que utilizarse, sin que pierda contexto por el camino.

Esto se conecta muchísimo con lo que pasa en una integración ERP-PIM. Una integración puede mover un valor sin un solo error técnico y, sin embargo, ese dato seguir siendo incorrecto. Antes de automatizar necesito saber qué sistema lo origina, quién lo gobierna y qué transformaciones están permitidas. Esa misma lógica aparece en los proyectos de integración que trabajo como analista PIM: mover información no es lo mismo que garantizar que la información sea confiable.

Cuando el dato es crítico, la gobernanza no es una capa burocrática agregada al catálogo. Es la forma de saber quién puede cambiar qué, con qué evidencia y bajo qué responsabilidad.

El PIM puede controlar el dato, pero no convertirse en autoridad regulatoria

Este límite me parece fundamental. Un PIM puede hacer muchísimas cosas útiles en un catálogo farmacéutico: estructurar información, diferenciar mercados, aplicar validaciones, controlar completitud, gestionar workflows, relacionar documentos, registrar estados y distribuir contenido hacia distintos canales.

Lo que no debería hacer es reemplazar a la fuente regulatoria ni al especialista responsable de interpretar sus requisitos.

Y yo tampoco.

No necesito jugar a ser farmacéutica ni especialista en regulación para hacer bien mi trabajo como analista PIM. Necesito entender qué información es crítica, cuál es su fuente autorizada, qué reglas tengo que preservar y qué persona debe intervenir cuando aparece una duda que excede mi rol.

Me parece una diferencia importante porque, en proyectos complejos, saber hasta dónde llega la responsabilidad de cada uno es tan valioso como saber qué tareas puede hacer. No todo problema se arregla desde el PIM. A veces el PIM tiene que garantizar que el problema correcto llegue a la persona correcta antes de convertirse en una publicación incorrecta.

Cuando el dato no admite error, la trazabilidad también forma parte de la calidad

En un catálogo menos regulado puedo evaluar calidad mirando dimensiones como completitud, consistencia, precisión y vigencia. Acá todas siguen importando, pero necesito agregar una capa operativa mucho más visible: poder reconstruir la historia del dato.

Quiero saber qué valor estoy usando, de qué fuente salió, para qué mercado aplica, cuándo fue revisado, si existe una versión posterior y quién autorizó su uso. No porque quiera llenar cada atributo de metadatos hasta volverlo inmanejable, sino porque esos datos me permiten dejar de depender de la memoria.

Y depender de la memoria es bastante cómodo hasta el día en que alguien pregunta: “¿Por qué publicamos esto?”. Si la respuesta está en la cabeza de una persona, en un mail de hace ocho meses o en una planilla que ya tiene tres copias, el dato puede ser correcto pero el proceso sigue siendo frágil.

En cambio, cuando puedo reconstruir la decisión, una actualización deja de significar empezar otra vez desde cero. Puedo entender qué cambió, qué sigue siendo válido, qué productos están afectados y dónde tengo que intervenir. Ese es el tipo de orden que busco.

Cuanto más crítico es un dato, menos me interesa que simplemente “esté cargado”. Quiero poder entender qué significa, de dónde salió, para qué contexto vale y qué recorrido hizo hasta llegar a esa ficha. En un catálogo regulado, para mí esa es la verdadera diferencia: la calidad no termina en el valor que veo en pantalla. También está en todo lo que me permite confiar en él.