Libro

Bigdata en salud: tecnologías emergentes y aplicaciones
José Luis González Compeán

María del Carmen Santiago Díaz
Miguel Morales Sandoval
Gustavo Trinidad Rubín Linares
Editores
Judith Pérez Marcial

Coordinadora
Primera Edición: Noviembre 2022

ISBN versión impresa: 978-607-8857-23-4
ISBN versión digital: 978-607-8857-25-8
Montiel & Soriano Editores S.A. de C.V.

15 sur 1103-6 Col. Santiago Puebla, Pue.
Centro de Investigación y Estudios Avanzados del Instituto Politécnico Nacional - CINVESTAV

Avenida Instituto Politécnico Nacional #2508 Col. San Pedro Zacatenco
C.P. 07360, Delegación Gustavo A. Madero, Ciudad de México.
CINVESTAV Unidad Tamaulipas

Dirección: Carretera Victoria- Soto la Marina Kilómetro 5.5,
Ciudad Victoria - Soto la Marina, 87130 Cd Victoria, Tamps.
Este trabajo ha sido financiado por el proyecto No. 41756 titulado "Plataforma tecnológica para la gestión, aseguramiento,
intercambio y preservación de grandes volúmenes de datos en salud y construcción de un repositorio nacional de servicios
de análisis de datos de salud" del fondo PRONACES-CONACYT.
ESTA OBRA, PARA SER PUBLICADA, FUE ARBITRADA A DOBLE CIEGO Y AVALADA POR EL SISTEMA DE
PARES ACADÉMICOS.
Esta publicación no puede ser reproducida ni en todo ni en parte, ni registrada en, o transmitida por un sistema de
recuperación de información, en ninguna forma ni por ningún medio, sea este mecánico, fotoquímico, electrónico,
magnético, electro-óptico, por fotocopia o cualquier otro sin el permiso previo por escrito de los autores.
Impreso y Hecho en México / Printed and bound in México

Seguridad y Privacidad de Datos en Sistemas de
Ciencia de Datos en Salud
Melissa Brigitthe Hinojosa-Cabello[0000−0002−0404−0398] , Miguel

Morales-Sandoval[0000−0003−1702−8467] , Diana Elizabeth
Carrizales-Espinoza[0000−0002−3925−031𝑋] , y José Luis
González-Compeán[0000−0002−2160−4407]
Centro de Investigación y de Estudios Avanzados del Instituto Politécnico Nacional,

Ciudad Victoria, Tamaulipas, 87130, México
{melissa.hinojosa,miguel.morales,diana.carrizales,
joseluis.gonzalez}@cinvestav.mx
Resumen El término Big Data se refiere a la producción de datos a gran

velocidad, de una gran variedad y con un alto volumen. En el ámbito de
la salud, Big Data se refiere a los procesos involucrados en la gestión,
almacenamiento, tratamiento y uso de datos médicos que pueden prove-
nir de distintas fuentes. En este contexto, paradigmas como el Internet
de las Cosas Médicas (IoMT) o el cómputo en la nube han acelerado la
producción masiva de datos en el área de la salud. Los datos origina-
dos en nodos IoMT (e.g., monitoreo de frecuencia cardiaca, niveles de
glucosa, etc.) se almacenan en la nube y después son consumidos o ac-
cedidos desde la misma por los usuarios finales (pacientes, profesionales
de la salud, personal médico, entre otros) a partir de diversas aplica-
ciones. Dada la naturaleza sensible de los datos médicos, que incluyen
información tanto personal como médica de los pacientes, resulta nece-
sario preservar el derecho a la privacidad. Si hay datos sensibles, éstos
deben estar protegidos en todo momento, durante el ciclo de vida de
los datos, ante cualquier divulgación o modificación no autorizada. Es
decir, los propietarios de los datos esperan que éstos únicamente estén
disponibles y puedan ser accedidos por usuarios autorizados, sin que el
proveedor del servicio u otras entidades no autorizadas sean capaces de
obtener y procesar dichos datos. En este sentido, los requerimientos de
seguridad que se deben cubrir son confidencialidad y control de acceso,
principalmente.
En este capı́tulo presentamos una descripción y detalles de construcción
del concepto de sobres digitales con capacidades de búsqueda, los cuales
son objetos criptográficos que permiten garantizar la privacidad de datos
sensibles, como los de salud. Ası́, los datos únicamente serán accedidos
por entidades autorizadas, descritas por un conjunto de atributos que
los caracterizan e identifican. De igual forma, el almacenamiento y re-
cuperación segura de datos médicos es indispensable en el desarrollo de
sistemas de ciencia de datos. Por ello, al final de este capı́tulo se describe
un caso de uso de los sobres digitales en este tipo de aplicaciones.
Palabras Clave: Confidencialidad · Control de Acceso · Sobres Digi-

tales · eSalud · Big Data.
10 M. B. Hinojosa-Cabello et al.
1. Introducción
La seguridad informática se refiere a todos aquellos mecanismos y recursos

utilizados para prevenir accesos no autorizados a los sistemas de información, que
incluyen recursos o infraestructura de cómputo, sistemas y datos. De entre éstos,
la seguridad de datos es la última lı́nea de defensa, ya que cuando un atacante
logra romper la seguridad de la red y del dispositivo, éste tiene la posibilidad
de acceder a los datos y comprometer su confidencialidad. En este capı́tulo, a
menos que se indique lo contrario, nos enfocamos únicamente en la seguridad de
los datos. Desde esta perspectiva, la seguridad de datos la abordamos desde dos
requerimientos principales: confidencialidad de datos y control de acceso hacia
éstos.
Definición 1. Confidencialidad [6], [7]: La confidencialidad garantiza la priva-
cidad de datos sensibles al impedir su divulgación mediante la restricción del
acceso a éstos a personas, recursos o procesos no autorizados, permitiendo que
únicamente aquellos con autorización legı́tima puedan acceder a los datos, con-
sumirlos o procesarlos. Éste es el requerimiento más antiguo y también el más
demandado cuando se habla de seguridad de datos.
Definición 2. Control de acceso [7]: El objetivo del control de acceso lógico es
la protección de cualquier tipo de recurso (datos, aplicaciones, servicios, entre
otros) de operaciones inadecuadas llevadas a cabo por usuarios malintencionados.
Éste consiste en la definición de una serie de restricciones, normalmente basadas
en polı́ticas, que describen quién puede acceder a los recursos y las operaciones
permitidas sobre éstos, e impiden el acceso no autorizado mediante soluciones
tecnológicas. El control de acceso involucra herramientas y protocolos para ges-
tionar el acceso a sistemas y recursos mediante la identificación, autenticación y
autorización de los usuarios.
La confidencialidad de datos puede alcanzarse mediante el cifrado de los mis-
mos. Cifrar significa, a grandes rasgos, una transformación de los datos (𝐷),
de un formato legible a uno ilegible (𝐶𝑇 ), mediante un procedimiento (𝑃 ) bien
definido y conocido. Para realizar dicha transformación se usa una llave crip-
tográfica 𝑘𝑐 que, en términos simples, corresponde a una secuencia de bits de
longitud 𝑛 con suficiente aleatoriedad. Este proceso de cifrado se representa por
la Ecuación 1. Una vez cifrados, los datos 𝐷 ya no son accesibles por nadie, salvo
por aquellos que posean una llave para descrifrar 𝑘𝑑 , y mediante un proceso in-
verso al cifrado (i.e., descifrado, 𝑃 −1 ) puedan transformar nuevamente los datos
cifrados 𝐶𝑇 en 𝐷, como se muestra en la Ecuación 2.
𝐶𝑇 = 𝑃 (𝐷, 𝑘𝑐 ) (1)
𝐷 = 𝑃 −1 (𝐶𝑇, 𝑘𝑑 ) (2)
En este sentido, la premisa del cifrado es que, para cualquier entidad que des-
conozca 𝑘𝑑 resulta prácticamente imposible obtener los datos legibles a partir del
Seguridad y Privacidad de Datos en Sistemas de Ciencia de Datos en Salud 11
texto transformado 𝐶𝑇 tras ejecutar 𝑃 −1 , incluso siendo éste un procedimien-

to bien conocido. Todos los cifradores, tanto antiguos como modernos, basan su
funcionamiento en los preceptos previamente descritos y, en principio, garantizan
el servicio de confidencialidad. Una vez cifrados, los datos pueden almacenarse
en un medio inseguro (e.g., en una unidad de disco), transmitirse también por
un medio inseguro (como internet), o enviarse a la nube. Sin embargo, es nece-
sario que el propietario de datos imponga y maneje las restricciones de acceso
a través de un control sobre las llaves de descifrado. Ante un escenario donde
existen grandes colecciones de datos que deben cifrarse para garantizar su con-
fidencialidad, como en el caso de big data en salud, se deben resolver al menos
tres problemáticas principales: eficiencia, compartición y recuperación.
La eficiencia: El cifrado, finalmente, es un requerimiento no funcional que

convella una sobrecarga, tanto en procesamiento como en almacenamiento,
para ejecutar los procedimientos 𝑃 y 𝑃 −1 . El nivel de seguridad está co-
rrelacionado con la longitud de la llave 𝑘𝑐 , por lo que entre más grande 𝑘𝑐 ,
mayor es el nivel de seguridad, pero también más lentos los procedimientos
𝑃 y 𝑃 −1 .
La compartición: Los datos generalmente no son consultados solo por el pro-
pietario de los mismos. En el caso de eSalud, los datos deben ser accedidos
por distintos actores, como los mismos pacientes, médicos, enfermeros, espe-
cialistas y, en general, profesionales de la salud. Ante un creciente volumen
de datos se hace evidente la necesidad de contar con mecanismos efectivos y
eficientes de control de acceso hacia dichos datos, para una compartición no
solamente segura, sino también eficiente.
La recuperación: Dado un gran volumen de datos, la recuperación de informa-
ción es necesaria para localizar rápidamente datos de interés y recuperarlos
para su acceso y consumo. Pero, ¿qué pasa si los datos están cifrados y, por
lo tanto, se encuentran en formato ilegible? ¿Cómo un motor de búsque-
da puede localizar y recuperar datos ilegibles de interés? Éste es uno de
los desafı́os más relevantes en el contexto del cifrado de grandes colecciones
de datos. Afortunadamente, existen mecanismos que permiten abordar este
problema, en lo que se conoce como Searchable Encryption (SE) [21]. Bajo
este enfoque, los usuarios de los datos pueden hacer búsquedas cifradas, esto
es, enviar al proveedor del servicio de almacenamiento de los datos cifrados
un ‘token’ que indica palabras clave en formato cifrado, de tal forma que
éste pueda usarlo para buscar en los datos cifrados y localizar aquellos que
empaten con los criterios de búsqueda. Al estar cifrados el token y los datos,
el servidor realiza algo parecido a una búsqueda a ciegas pero efectiva, recu-
perando los datos de interés sin aprender acerca de los criterios de búsqueda
o de los datos localizados. Sin embargo, no cualquier esquema SE podrı́a ser
adecuado para un entorno particular.
En este capı́tulo presentamos el concepto, diseño, implementación y evalua-

ción en un caso de uso de sobres digitales con capacidades de búsqueda (SDB),
Política de búsqueda
Datos médicos sensibles SE ABE

1:m
SDB
Productor Cifrado
ABE ‐ 1:m
Política de descifrado
Búsqueda cifrada
Definidos por
un conjunto
de atributos Búsqueda cifrada
Usuarios Búsqueda cifrada
Descifrado
Llave de usuario ABE
Figura 1: Vista general del concepto de sobres digitales con capacidades de

búsqueda y su aplicación en el dominio de big data en salud.
los cuales son abstracciones fundamentadas en el cifrado de datos no convencio-

nal, llamado cifrado basado en atributos (ABE) [17]. Mediante ABE y bajo el
concepto de SDB abordamos los tres problemas previamente descritos. En las
siguientes secciones se darán detalles tanto de ABE como de su implementación
con capacidades de búsqueda (SE-ABE). Por ahora, el enfoque de solución y
concepto de SDB se muestra en la Figura 1. Con base en ello, el proceso de
aseguramiento de datos sensibles en salud mediante SDB se lleva a cabo de la
siguiente forma:
1. El productor de datos, que generalmente es un médico, especialista en salud,

o incluso algún dispositivo médico, genera datos sensibles, como radiografı́as;
2. Estos datos en algún momento serán requeridos por otro médico o profe-
sional de la salud, incluso por el mismo paciente; al ser las radiografı́as en
nuestro ejemplo datos sensibles, éstas no pueden almacenarse en un disco o
memoria, o enviarse mediante correo o algún servicio de mensajerı́a a través
de un teléfono inteligente; los datos deben asegurarse y almacenarse en un
medio desde el cual después dichos datos puedan recuperarse; para ello, el
productor de los datos debe ejecutar dos macro-procesos: 𝑖) el algoritmo de
cifrado ABE, el cual requiere de una polı́tica de control de acceso que, en
esencia, determina qué usuarios podrán descifrar esos datos más adelante;
𝑖𝑖) el algoritmo de búsquedas cifradas SE-ABE, el cual también requiere de
una polı́tica de control de acceso, pero que determina qué usuarios podrán
consultar los datos cifrados mediante tokens igualmente cifrados;
3. Tanto el cifrado ABE como parte de la búsqueda cifrada SE-ABE se ejecutan

del lado del productor de datos; el resultado de cada proceso es, por un lado,
los datos cifrados y, por otro, un ı́ndice seguro de búsqueda sobre los datos
cifrados; todo esto es lo que conforma el SDB;
4. Una vez creado, el SDB es enviado a un repositorio (la nube), de donde más
adelante los usuarios autorizados podrán hacer consultas (si sus atributos
satisfacen la polı́tica usada en SE-ABE), recuperar la información de interés
(cifrada) y acceder a ella descifrándola usando su llave de usuario estrecha-
mente relacionada con los atributos que le describen (médico, enfermera,
paciente y demás datos relacionados con dicho rol);
5. Un usuario de los datos está descrito por los atributos que lo caracterizan;
por ejemplo, un profesional de la salud puede tener atributos como su es-
pecialidad, nivel jerárquico en la organización donde labora, datos del lugar
donde labora que describen su pertenencia a dicha organización, datos per-
sonales y cualquier otro que sea relevante para el propósito; con base en
estos atributos, cada usuario cuenta con una llave, la cual es intransferible
y necesaria para crear los tokens de búsqueda y para descifrar los datos
recuperados desde el repositorio de datos cifrados.
Nuestra construcción de SDB se realiza sobre emparejamientos bilineales

asimétricos, los cuales son estructuras matemáticas en el dominio de la teorı́a
de grupos y campos finitos. Con ello, ABE no solo es lo suficientemente seguro
para preservar la confidencialidad de los datos, sino también para garantizar el
control de acceso a éstos únicamente a entidades especı́ficas mediante el cifrado
de uno a muchos. Asimismo, se habilitan las búsquedas cifradas también bajo el
concepto de cifrado basado en atributos, reutilizando las estructuras algebraicas
de esta técnica criptográfica. El cifrado de datos en SDB consta de dos capas
de cifrado a partir de las cuales se toma ventaja a la par de la eficacia y del
elevado nivel de seguridad provisto por ABE y de la eficiencia de los cifradores
simétricos [18]. Los datos sensibles son cifrados mediante llaves de sesión de un
cifrador simétrico, mientras que las llaves de sesión se cifran a partir de ABE.
De esta forma, es posible preservar la confidencialidad de los datos y decidir
selectivamente los usuarios autorizados para acceder y consumir determinados
conjuntos de datos.
Este capı́tulo está organizado de la siguiente manera: en la Sección 2 presen-
tamos los conceptos más relevantes para la definición de los SDB; en la Sección 3
se presentan los detalles de diseño de sobres digitales, mientras que en la Sección
4 se presenta el diseño de los SDB; en la Sección 5 se describen las estrategias
de eficiencia y paralelismo de los SDB, mientras que en la Sección 6 se detalla la
validación de la construcción de SDB en el dominio de la salud, siendo un com-
ponente principal en el despliegue de un servicio que permite el aseguramiento
de datos médicos desde su producción hasta su consumo [4]; en la Sección 7 se
discuten, desde la perspectiva de este trabajo, los retos para proteger los datos
en el sector salud; finalmente, en la Sección 8 se presentan las conclusiones.
2. Antecedentes
Dı́a con dı́a, usuarios e instituciones generan y recolectan grandes cantidades

de datos derivados de actividades cotidianas, tales como compras en lı́nea, reali-
zación de trámites, transacciones bancarias, entre muchas otras. Gran parte de
estos datos se encuentra disponible de forma pública en sitios web o redes socia-
les, por citar algunos ejemplos. Sin embargo, existen datos que son sensibles y
requieren protección ante el acceso no autorizado por parte de terceros [6]. Ejem-
plos de datos sensibles son los registros médicos o financieros, números de cuenta
bancarios, datos de identificación personal o número de seguridad social; planes
de adquisición, información personal de clientes, datos financieros o derechos de
propiedad intelectual. De esta forma, a medida que se generan y distribuyen
grandes cantidades de datos, la protección de éstos se vuelve indispensable para
sus propietarios, ya sean individuales o grandes empresas e instituciones.
La importancia de la seguridad de la información radica en la protección de
los datos y sistemas que los producen o utilizan del daño, uso, divulgación o
destrucción no autorizados [11]. Con el volumen y variedad de datos, ası́ como
la velocidad con la que éstos son generados por los usuarios y las operaciones
diarias del negocio, la confidencialidad, integridad y disponibilidad de los datos
son esenciales para la seguridad de la información [6]. Uno de sus principios fun-
damentales es la confidencialidad, la cual garantiza la privacidad de los datos al
restringir el acceso a éstos través del cifrado de su contenido. Para ello, se apoya,
además, en mecanismos de autenticación o concesión de niveles de privilegios,
permitiendo que solamente personas autorizadas puedan ver o manipular datos.
De esta manera se evita que entidades no autorizadas puedan derivar u obtener
información a partir de dichos datos [6], [7].
2.1. Criptografı́a
Uno de los métodos más utilizados para asegurar la confidencialidad de los

datos es el cifrado. La criptografı́a se encarga de implementar el cifrado realizan-
do transformaciones a los datos de manera que, al almacenarlos y transmitirlos,
solo los destinatarios autorizados puedan accederlos y procesarlos [10]. Dichas
transformaciones se llevan a cabo del lado de los propietarios de datos, con-
virtiendo información legible en texto incomprensible, y de los destinatarios,
aplicando el proceso inverso de descifrado para obtener los datos originales [12],
[10]. Los métodos criptográficos modernos emplean algoritmos seguros desde el
punto de vista computacional con la finalidad de que la información protegida
no pueda ser comprometida fácilmente. Dicho objetivo se logra mediante meca-
nismos como el cifrado de los datos o de los canales de comunicación durante su
transmisión, ası́ como la generación de códigos de autenticación de mensajes y
firmas digitales [12], [7].
Los procesos de cifrado y descifrado requieren dos componentes elementales:
un algoritmo criptográfico, o cifrador, y una llave. El algortimo consiste en la
aplicación de funciones matemáticas que, en conjunto con una llave que se utiliza
como parámetro de entrada durante el procedimiento, realizan las transforma-

ciones pertinentes a los datos [12]. Al llevar a cabo el cifrado de los datos, éstos
se protegen al convertir su forma legible en texto cifrado que resulta incompren-
sible. En contraste, el descifrado constituye el proceso opuesto, a partir del cual
se obtienen los datos sensibles al remover la protección suministrada a través del
cifrado [7]. Por otra parte, la llave o clave criptográfica es un componente indis-
pensable de cualquier algoritmo de cifrado. Usualmente, estas claves se generan
de manera aleatoria previa al cifrado de los datos, aunque éstas también pueden
ser especificadas por el usuario [12], [11].
Cabe destacar que la ventaja del uso de un algoritmo sobre otro radica en
la eficacia de la generación y administración de las llaves utilizadas para los
procesos de cifrado y descifrado. Cuanta mayor dificultad asociada a la clave
criptográfica, mayor seguridad será capaz de brindar el algoritmo; no obstante, su
ejecución se vuelve más compleja. En consecuencia, la seguridad del cifrado reside
sustancialmente en el secreto de las claves, no en el algoritmo. En la actualidad,
existen diversos algoritmos de cifrado y, debido a que éstos son de acceso público,
las claves criptográficas que dichos algoritmos utilizan son las que garantizan
la discreción de los datos [7]. Son diversos los sistemas criptográficos que han
presentado fallas debido a errores en sus procedimientos de administración de
llaves. En la práctica, la mayorı́a de los ataques implican vulnerar el sistema
de gestión de claves, en lugar del algoritmo criptográfico en sı́. Es por ello que
la gestión de claves constituye la parte más difı́cil de abordar al momento de
diseñar un sistema criptográfico.
Cada método de cifrado utiliza un algoritmo especı́fico (𝑃 , como ha sido
descrito en la Ecuación 1) que se compone de una serie de pasos bien definidos,
generalmente estandarizados, utilizados para cifrar y descifrar los datos. Existen
diversos métodos para crear texto cifrado, siendo los más antiguos la transposi-
ción o sustitución de caracteres y, el más reciente, la combinación de datos con
claves secretas. Si bien los algoritmos de cifrado contemporáneos emplean técni-
cas más robustas basadas en problemas matemáticos, no hay un algoritmo que
resulte idóneo para cualquier caso de aplicación. La adopción de éste dependerá
del nivel de sensibilidad y cantidad de información que se requiera proteger, ası́
como de los inconvenientes que se pretendan mitigar. Asimismo, la forma de al-
macenamiento o de transmisión de los datos y los recursos computacionales con
los que se cuente determinarán, en gran medida, la opción que habrá de elegirse
para llevar a cabo esta tarea [22], [7]. Según la manera en que se gestionen las
llaves, los algoritmos criptográficos se pueden dividir en simétricos y asimétricos.
2.2. Criptografı́a de Clave Privada: Cifradores Simétricos
Los algoritmos simétricos se caracterizan por hacer uso de una cantidad me-
nor de recursos computacionales que su contraparte asimétrica. Esto se debe a
que en el cifrado simétrico se utiliza una misma llave para realizar el cifrado
y descifrado de los datos, tal como se observa en la Figura 2. A esta llave se
le denomina clave secreta o previamente compartida, ya que el emisor y recep-
Figura 2: Flujo de operaciones en el cifrado simétrico.
tor deben conocerla antes de que inicie el proceso de cifrado [7], [12]. Dado un
mensaje, la clave secreta sirve como parámetro de entrada para el algoritmo de
cifrado que aplica las transformaciones necesarias para producir como salida un
texto cifrado. Cabe destacar que dicho mensaje se procesa a nivel de arreglos de
bytes, por lo que éste puede representar desde una cadena de caracteres hasta un
archivo de cualquier extensión. Por el contrario, el algoritmo de descifrado recibe
como entrada el texto cifrado, ası́ como la misma clave previamente compartida,
y produce como resultado el texto plano del mensaje original.
Los algoritmos simétricos pueden dividirse en cifradores por bloque o por
flujo en función de la cantidad de datos de entrada que manejan. Es decir, la
diferencia entre ambos recae en la forma de realizar el agrupamiento de bits
para los procesos de cifrado y descifrado. Los algoritmos de cifrado por bloque
dividen los datos de entrada en bloques de tamaño fijo, usualmente de 64 ó 128
bits, y posteriormente realizan el procesamiento de dichos bloques. En cambio,
los cifradores por flujo procesan los datos de entrada conforme éstos se van
recibiendo, esto es, un byte o un bit a la vez [7]. De acuerdo con Barker [2], el
estándar de cifrado avanzado (AES) es el algoritmo recomendado en la actualidad
por el Instituto Nacional de Estándares y Tecnologı́a (NIST) para el cifrado-
descifrado de datos. AES es un cifrador por bloque desarrollado para reemplazar
al ya obsoleto estándar de cifrado de datos (DES), por lo que constituye el
algoritmo más utilizado en la actualidad. Este algoritmo procesa datos en bloques
de 128 bits utilizando claves de 128, 192 ó 256 bits, con lo cual se considera que
es capaz de proveer niveles de seguridad válidos más allá del año 2030.
2.3. Criptografı́a de Clave Pública: Cifradores Asimétricos
Para el cifrado y descifrado, los algoritmos asimétricos utilizan un par de cla-

ves –una pública y otra privada– matemáticamente relacionadas entre sı́, lo cual
implica que estos algoritmos sean más complejos que su contraparte simétrica.
Si bien existe una relación matemática entre las claves, no es posible obtener
la llave privada a partir de la llave pública debido a la complejidad de las ope-
raciones involucradas en la generación del par de claves. Es por ello que estos
algoritmos requieren una mayor cantidad de recursos computacionales y su pro-
Figura 3: Flujo de operaciones en el cifrado asimétrico.
ceso de ejecución es más lento. En el ejemplo expuesto en la Figura 3, en un

sistema de cifrado de clave pública el emisor cifra los mensajes utilizando la cla-
ve pública de un receptor en particular [12], [11]. De esta forma, únicamente la
clave privada asociada a la clave pública usada para el cifrado puede descifrar
los datos. Debido a ésto, no es necesario que ambas partes hagan uso de una
llave previamente compartida para intercambiar mensajes de manera segura.
Al igual que en la criptografı́a de clave privada, los algoritmos asimétricos son
de acceso público, por lo que es posible conocer cómo trabajan de manera general.
Sin embargo, sus operaciones se basan en problemas matemáticos complejos pero
bien conocidos, como la factorización de enteros y los logaritmos discretos. Dado
lo anterior, la seguridad de este tipo de algoritmos recae en el par de claves
de las cuales se hace uso en los procesos de cifrado y descifrado [7]. Al utilizar
funciones del álgebra abstracta en lugar de números reales se vuelve poco viable
la búsqueda de la clave privada asociada a una clave pública, incluso si se conoce
con qué algoritmo se crearon ambas, dado el tiempo computacional requerido
y el elevado costo asociado a dicho procedimiento [12]. Rivest-Shamir-Adleman
(RSA), Diffie-Hellman (DH), ElGamal y la criptografı́a de curva elı́ptica (ECC)
son ejemplos de algoritmos asimétricos utilizados hoy en dı́a.
Como se puede observar, existen evidentes diferencias entre los algoritmos
simétricos y asimétricos.
Los primeros son más eficientes en cuanto al tiempo de procesamiento requeri-

do y la cantidad de datos que pueden manejar, pero la gestión de claves es mucho
más difı́cil por el uso de claves compartidas. Otra de las grandes diferencias entre
ambos es el tamaño de las llaves, lo cual determina su susceptibilidad a ataques
por fuerza bruta. Al ser las claves asimétricas de mayor tamaño en comparación
con las claves simétricas –1024 bits contra 128 bits, respectivamente–, el rango
de valores posibles es también mucho mayor, lo cual hace inviables este tipo de
ataques [11]. En la práctica, ambos esquemas se utilizan en conjunto: el cifrado
simétrico se utiliza para garantizar la confidencialidad de grandes volúmenes de
datos y la criptografı́a de clave pública para el intercambio de las claves secretas.
(doctor AND cardiólogo) OR

(doctor AND internista) OR doctor
enfermera
internista
nivel B
Figura 4: Flujo de operaciones en el cifrado basado en atributos.
2.4. Cifrado Basado en Atributos
El cifrado basado en atributos (ABE) es una técnica de la criptografı́a de

clave pública que tiene su fundamento en un mecanismo de control de acceso en
el que una entidad se identifica a partir de un conjunto de atributos descriptivos.
Éste permite compartir datos de forma segura con múltiples usuarios, a la vez
que ofrece una gran flexibilidad de gestión de acceso a los datos [17], [1]. En
lugar de utilizar las tradicionales claves públicas o privadas, en ABE los datos
se cifran mediante la especificación de los atributos que un potencial usuario
debe poseer para poder descifrar un mensaje utilizando su clave secreta, tal
como se muestra en la Figura 4. Dichos atributos se especifican en estructuras
denominadas polı́ticas de control de acceso, las cuales establecen las reglas de
acceso a los datos de los propietarios mediante compuertas lógicas (AND, OR)
o de tipo umbral (k-of-n) [14].
Cabe mencionar que, a diferencia de otros algoritmos de clave pública, ABE
es un esquema de cifrado de muchos a muchos, por lo que los propietarios de
datos no tiene que conocer de antemano a todos los posibles usuarios. Dado que
los algoritmos asimétricos tradicionales utilizan un par de claves relacionadas
matemáticamente, un mismo mensaje se tiene que cifrar tantas veces como des-
tinatarios existan para éste. Por el contrario, puesto que en ABE un atributo
puede ser común a múltiples usuarios, el cifrado mediante polı́ticas de acceso
permite abarcar un mayor número de destinatarios. Esta caracterı́stica repre-
senta una de las principales ventajas de este esquema, ya que permite un control
de acceso de grano fino, sin incurrir en sobrecargas de almacenamiento y co-
municación asociadas a algoritmos como RSA [19]. De este modo, ABE resulta
más adecuado para escenarios de almacenamiento y compartición de datos en la
nube, ya que los datos de los propietarios permanecen confidenciales incluso en
entornos poco confiables.
3. Sobres Digitales
Como se mencionó anteriormente, la confidencialidad de datos sensibles se

logra a partir del cifrado, y éste puede realizarse mediante algoritmos simétricos
o asimétricos. Ambos realizan transformaciones a los datos de modo que sola-
mente aquellos destinatarios que posean la correspondiente llave de descifrado
Encapsulamiento de la Llave Desencapsulamiento de la Llave
Cifrado de los Datos Descifrado de los Datos
(a) Criptografı́a de clave pública tradicional.
Encapsulamiento de la Llave
Desencapsulamiento de la Llave
(doctor AND cardiólogo) OR
(doctor AND internista) OR doctor
enfermera
internista
nivel B
Cifrado de los Datos Descifrado de los Datos
(b) Cifrado basado en atributos.
Figura 5: Flujo de operaciones en la creación y uso de sobres digitales.
puedan acceder a dichos datos. Sin embargo, estos dos tipos de cifradores con-
llevan desventajas que dificultan su uso de forma aislada; por ello, éstos suelen
emplearse de forma conjunta en aplicaciones prácticas. La ventaja de los algorit-
mos simétricos sobre los asimétricos es la capacidad de cifrar una gran cantidad
de datos eficientemente en términos de tiempos de respuesta. No obstante, éstos
implican un problema de distribución y gestión de llaves debido a que la llave
usada para cifrar es la misma requerida por el proceso de descifrado. Ası́, es
necesario que los propietarios de datos compartan las claves de descifrado con
los destinatarios de dichos datos a través de canales de comunicación seguros,
algo que no es posible garantizar en todos los casos.
En este sentido, una forma de sortear el problema de compartición de claves es
mediante el uso de una técnica criptográfica denominada sobre digital. Un sobre
digital se define como un objeto criptográfico que consta de dos capas de cifrado
a partir de las cuales se transporta y distribuye una llave de sesión de forma
segura. Mediante éstos, es posible tomar ventaja simultáneamente tanto de la
criptografı́a de clave pública, como de la criptografı́a de clave privada. Como se
puede observar en la Figura 5a, los datos sensibles son cifrados mediante llaves
de sesión de cifradores simétricos, mientras que dichas llaves de sesión se cifran o
encapsulan a partir de criptografı́a de clave pública. Es decir, los datos se cifran
y descifran con una misma llave simétrica, que a su vez se cifra utilizando la clave
pública del destinatario de los datos y éste los descifra usando su clave privada.
De esta forma es posible preservar la confidencialidad de una gran cantidad de
datos en un tiempo razonable, mientras que es posible compartir las llaves de
descifrado con destinatarios especı́ficos, aun utilizando canales de comunicación
inseguros.
Además de proporcionar mayor robustez contra ataques, los algoritmos asimé-
tricos eluden el problema de compartición de llaves al utilizar un par de claves
relacionadas matemáticamente. No obstante, dada dicha relación entre llaves,
es necesario conocer a priori a los potenciales usuarios de un mismo conjunto
de datos. Por ello, una forma de abordar esta problemática en el contexto de
los sobres digitales implica la remoción del algoritmo asimétrico empleado y la
incorporación en su lugar del cifrado basado en atributos, tal como se muestra
en la Figura 5b. De esta manera, ABE permite compartir datos de forma se-
gura con múltiples usuarios, incluidos aquellos no definidos a priori. Solamente
aquellos usuarios que posean un conjunto de atributos que satisfaga de forma
criptográfica la polı́tica de control de acceso definida previo al cifrado podrán
acceder a los datos en texto plano. Es decir, únicamente quienes cumplan con los
criterios establecidos en la polı́tica de acceso podrán acceder a la llave de sesión
y, con ella, a los datos sensibles.
De esta manera, al emplear sobres digitales en conjunto con ABE desaparece
la necesidad de implementar mecanismos adicionales de gestión de llaves. Lo
anterior, considerando que los atributos permiten describir las caracterı́sticas
de los usuarios, ası́ como sus inherentes derechos de acceso. De esta forma, se
evitan sobrecargas de cómputo, resulta poco significativo si la transmisión de
datos se realiza mediante canales de comunicación seguros o no, y se impone un
control de acceso de grano fino. Incluso si un sobre es filtrado pero su portador no
cuenta con los atributos que satisfacen la polı́tica utilizada en la creación de dicho
sobre, éste no será capaz de acceder al contenido legible del sobre digital. Cabe
destacar que, a partir de los atributos que posean los usuarios, una autoridad
de confianza (TA) se encarga de generarle a cada usuario su correspondiente
llave secreta, la cual permite corroborar si éste satisface la polı́tica utilizada
en el cifrado. Además, la TA tiene la facultad de implementar mecanismos de
revocación de acceso para el caso de aquellos usuarios que dejen de pertenecer a
la organización donde se gestionan los datos sensibles o aquellos que hagan uso
indebido de los mismos.
4. Sobres Digitales con Capacidades de Búsqueda

El cifrado de datos permite garantizar la confidencialidad de datos sensibles
en entornos poco confiables, como en el caso de escenarios de almacenamiento en
la nube. Asimismo, el almacenamiento en la nube facilita el acceso conveniente
a los datos y su compartición con múltiples usuarios, proveyendo, además, ca-
pacidades de búsqueda y recuperación de información. Sin embargo, el hecho de
que los propietarios cifren sus datos previo a externalizarlos a la nube introduce
dos grandes problemas. En primer lugar, la compartición se vuelve una tarea
compleja que implica que los propietarios gestionen los mecanismos de control
de acceso hacia sus datos. Dicha problemática se puede abordar a través del uso
de ABE, el cual ofrece una gestión flexible mediante controles de acceso de grano
fino a la vez que garantiza la confidencialidad de los datos. En segundo lugar,
las capacidades de búsqueda del proveedor del servicio de almacenamiento no se
pueden aprovechar debido a que los datos se encuentran en formato ininteligible.
Si bien los usuarios podrı́an descargar todos los datos (cifrados), descifrarlos
y aplicar localmente algoritmos de búsqueda y recuperación tradicionales, este
enfoque es totalmente inviable en la práctica por varias razones. Por ejemplo,
se introducen sobrecargas de comunicación innecesarias al descargar todo un
conjunto de datos que, en el peor de los casos, pudiera no contener información
relevante. Además, se generan sobrecargas de procesamiento donde, al poseer
recursos heterogéneos, no todos los dispositivos pueden ejecutar procedimientos
exhaustivos de búsqueda. En este contexto, surge Searchable Encryption (SE),
una técnica criptográfica que permite realizar búsquedas sobre datos cifrados. Su
objetivo es mantener la confidencialidad de los datos mientras el proveedor del
servicio de almacenamiento es capaz de preservar sus capacidades de búsqueda
[5]. SE ha sido implementado mediante tres enfoques principales, siendo el cifrado
basado en atributos con capacidades de búsqueda (ABSE) el más adecuado para
escenarios de almacenamiento y compartición de datos cifrados.
ABSE se apoya en la creación de un ı́ndice seguro que contiene palabras
clave representativas del contenido o caracterı́sticas de los datos sensibles y, a
partir del cual, posteriormente se realizan las búsquedas [1]. Al ser un enfoque
basado en atributos, ABSE opera de forma muy similar a ABE: se emplean
polı́ticas para establecer reglas de acceso y atributos para describir a los usuarios
y, por ende, sus restricciones de acceso. Tras identificar las palabras clave que
describen el contenido de los datos, éstas se cifran una sola vez mediante una
polı́tica de acceso, definida sobre un conjunto de atributos y, a partir de ellas, se
construye el ı́ndice seguro. Una vez creado éste, tanto los datos sensibles como
su correspondiente llave de sesión son cifrados, produciendo el sobre digital que
habrá de enviarse en conjunto con el ı́ndice seguro para su almacenamiento en la
nube [9]. Cabe resaltar que la polı́tica de acceso utilizada para cifrar las palabras
clave puede ser la misma o una polı́tica diferente a la usada para cifrar la llave
de sesión, dependiendo de las necesidades de acceso que caractericen a los datos.
Este proceso se ilustra en la Figura 6a.
Para realizar las búsquedas, el ı́ndice seguro es consultado por el proveedor
del servicio de almacenamiento dado un token cifrado, denominado trampilla de
búsqueda o trapdoor, creado por el usuario que solicita una búsqueda. Al igual
que en ABE, cada usuario posee una llave secreta que se genera con base en el
conjunto de atributos que lo caracterizan. De este modo, solo los usuarios que
poseen el conjunto de atributos adecuados (dada una polı́tica) pueden buscar y
recuperar datos de interés [1], [13]. Derivado de una necesidad de información,
a partir de la clave secreta de usuario se genera una representación cifrada de
la consulta del usuario, la cual permite realizar la búsqueda en el ı́ndice seguro
[20]. Por ello, es importante señalar que el proveedor de servicio no es capaz de
Creación del Índice Seguro
...
Palabras Clave radiólogo OR (doctor
AND reumatólogo)
presencia de osteofitos
inflamación sinovial
tejidos conjuntivos
posible osteoartritis
Cifrado de los Datos
(a) Creación del ı́ndice seguro y cifrado.
Creación del Trapdoor
doctor
reumatólogo
nivel D
g
tejidos
conjuntivos
Búsqueda y Recuperación de Datos
...
Descifrado de los Datos
(b) Creación del trapdoor, búsqueda y descifrado.
Figura 6: Flujo de operaciones en la creación y uso de sobres digitales con capa-

cidades de búsqueda.
derivar información, saber qué está buscando o el contenido de los resultados

que encuentra dado un trapdoor en particular.
Si los atributos del potencial usuario de los datos satisfacen la polı́tica de
cifrado y si existen resultados para su consulta, se retornan los sobres digitales
correspondientes. Finalmente, el usuario podrá descifrar la llave de sesión me-
diante su clave secreta y los datos por medio de dicha llave de sesión, tal como
se muestra en la Figura 6b [9], [20]. De esta forma se garantiza confidencialidad
y control de acceso, ası́ como la capacidad de compartir datos de forma segura
con múltiples usuarios al incorporar ABE en el contexto de los sobres digitales.
Además, se preservan las capacidades de búsqueda y recuperación de informa-

ción del proveedor del servicio de almacenamiento al hacer uso de esta técnica
en conjunto con el cifrado con capacidades de búsqueda.
5. Eficiencia y Seguridad de Sobres Digitales
Crear y abrir SDBs requiere suficiente poder de cómputo. La complejidad

en tiempo de ejecución y demanda de recursos de cómputo está asociada a los
algoritmos criptográficos para cifrar los datos con el cifrador simétrico y para
proteger la llave de sesión de dicho cifrador simétrico mediante el cifrado basado
en atributos. Esta complejidad queda determinada por:
El tamaño de los datos a cifrar, que impacta directamente en la complejidad

en tiempo para el cifrador simétrico;
El nivel de seguridad, que impacta directamente en el número de operaciones
y la longitud de los operandos del cifrado basado en atributos.
El problema de eficiencia en SDBs se aborda a través del uso de patrones

de paralelismo. El problema de la seguridad en SDBs se aborda mediante cons-
trucciones basadas en emparejamientos asimétricos. Se consideran dos esquemas
de paralelismo: 𝑖) pipeline; y 𝑖𝑖) overlapped. En el esquema llamado pipeline se
despliegan dos patrones de paralelismo diferentes: el patrón pipe & filters en
combinación con el patrón conocido como manejador/trabajador. De esta mane-
ra, el patrón pipe & filters se encarga de organizar el sistema en tuberı́as y el
patrón manejador/trabajador se encarga de desplegar dichas tuberı́as como tra-
bajadores ejecutados en paralelo. Este esquema se encarga de cifrar y descifrar
SDB1
SDB2
Datos
médicos
SDBq
SDBi
Figura 7: Representación conceptual de un esquema pipeline.
1- Patrones de paralelismo: Una descripción de los patrones de paralelismo que se

usan para la aceleración de la ejecución de la creación de los sobres digitales en
Zamna.
En Muyal-Zamna, se han definido dos esquemas de paralelismo que permiten eficientizar el

uso de los bloques de seguridad que permiten brindar a los datos de las características de
confidencialidad, integridad, control de acceso, trazabilidad y no repudio: i) pipeline, y ii)
conjuntos pequeños de datos dividiendo las tareas entre el número de trabaja-

dores disponibles desplegados en el sistema, lo cual permite reducir el tiempo
de ejecución de los procesos de cifrado, los cuales dependen del tamaño de los
datos, más que del nivel de seguridad.
La Figura 7 muestra la representación conceptual del ejemplo de un esquema
pipeline, el cual cuenta con un patrón pipe & filters que incluye las aplicaciones de
AES (como cifrador simétrico), CP-ABE (como cifrador basado en atributos) y
SSign (para firma digital, basado en identidad). En este esquema, cada tuberı́a
es clonada en 𝑞 trabajadores para eficientizar el procesamiento de los datos
mediante la distribución de tareas a través de un trabajador dedicado. Una
vez que los datos, expresados como archivos 𝑡𝑖 en un repositorio de entrada,
son procesado a través de toda la tuberı́a por un trabajador dedicado, éstos se
encapsulan para dar origen al SDB𝑖 correspondiente, que puede ser enviado a su
destino.
PorFigura
otro 1.lado,
Ejemplo de un esquema de paralelismo “Pipeline” construido con Muyal‐Zamna.
el esquema overlapped permite el acoplamiento de sistemas
independientes para que se ejecuten de forma suprapuesta (mediante el patrón
Por otro lado, el ysegundo
fork/join), esquema
el acoplamiento en (overlapped)
forma de tuberı́a permiteparaelaquellos
acoplamiento
sistemasdeque sistemas
independientes paraalgún
cuenten con que se ejecuten
tipo de forma suprapuesta
de dependencia. Este esquema(mediante
permite queel patrón fork/join), y
los proce-
el acoplamiento en forma
sos asociados con lade tuberíade
creación para aquellos
SDBs sistemas
se ejecuten en que
forma cuenten
de unacon algúny tipo de
tuberı́a
dependencia. Este esquema permite que los procesos se ejecuten en forma de una tubería y
se gestionen como si fueran trabajadores en un patrón manejador/trabajador,
se gestionen como que
permitiendo si fueran trabajadores
la ejecución de tareasenseunrealice
patrón demanejador/trabajador
forma paralela. El esquema permitiendo
que la ejecución de tareas se realice de forma paralela. El esquema
overlapped fue diseñado para cifrar y descifrar grandes overlapped
conjuntos fue de
de datos diseñado
forma paralela.
para cifrar/descifrar conjuntos grandes de datos (por ejemplo, proteger archivos utilizando
un nivel de seguridad de 192 y 256 bits) de forma paralela.
SDB1
Datos
médicos
SDBp
SDBi
Figura
Figura 8: Representación
2 Ejemplo conceptual
de un esquema de paralelismo de un esquema
“Overlapped” overlapped.
construido con Muyal‐Zamna.
La Figura 2 muestra la representación conceptual de un ejemplo de un esquema overlapped,

en donde un conjunto de tareas es extraído desde una fuente de datos, y posteriormente
estos son distribuidos a los trabajadores a través de un manejador. Cada trabajador contiene
un patrón fork/join el cual permite la ejecución de tareas de forma suprapuesta (en este caso,
la ejecución de la generación de llaves al mismo tiempo que la ejecución de la firma digital
de los contenidos). Esto permite ejecutar dos tuberías al mismo tiempo, y una vez que la
ejecución de ambas tuberías ha terminado, el contenido procesado es integrado en un sobre
La Figura 8 muestra la representación conceptual de un ejemplo de un es-

quema overlapped, en donde un conjunto de tareas es extraı́do desde una fuente
de datos y, posteriormente, éstas son distribuidas a los trabajadores a través de
un manejador. Cada trabajador contiene un patrón fork/join, el cual permite
la ejecución de tareas de forma suprapuesta (en este caso, la ejecución de la
generación de llaves al mismo tiempo que la ejecución de la firma digital de los
contenidos). Esto permite ejecutar dos tuberı́as al mismo tiempo y, una vez que
la ejecución de ambas tuberı́as ha terminado, el contenido procesado es integra-
do en un sobre digital y, posteriormente, enviado a un destino (ya sea para su
consumo, compartición o procesamiento en un entorno distinto).
6. Sobres Digitales para Ciencia de Datos

Hasta nuestro conocimiento, los SDBs han sido explorados y propuestos como
tal, por primera vez, en el grupo de investigación del Cinvestav Unidad Tamauli-
pas [9]. De igual forma, y en el marco del programa de apoyo a la investigación en
salud PRONACES - Salud, PRONAII Ciencia de Datos en Salud, en el proyecto
“Plataforma tecnológica para la gestión, aseguramiento, intercambio y preserva-
ción de grandes volúmenes de datos en salud y construcción de un repositorio
nacional de servicios de análisis de datos de salud” [15], se han implementado
los sobres digitales para garantizar la seguridad, de extremo a extremo, de los
datos médicos durante su ciclo de vida, que incluye:
1. Creación: Los datos se originan en un dispositivo médico (como radio-

grafı́as, por ejemplo) o sistema de información (expediente clı́nico electróni-
co).
2. Almacenamiento: Una vez creados, los datos se encapsulan en SDBs y se
almacenan en repositorios, locales o externos. En el caso de usar medios de
almacenamiento externo, la comunicación desde el origen al destino se realiza
comúnmente por un medio público o inseguro. Las propiedades de seguridad
inherentes de los SDBs permiten emplear, incluso, canales de comunicación
inseguros.
3. Uso: Los datos que ya se encuentran en un repositorio pueden ser consumidos
o consultados por usuarios autorizados mediante técnicas de búsqueda, recu-
peración y acceso a SDB. Las caracterı́sticas inherentes a los SDBs permiten
realizar estas operaciones que habilitan a los usuarios autorizados (médi-
cos, especialistas, profesionales de la salud, u otros dispositivos o sistemas)
acceder a los datos de manera segura.
La Figura 9 describe de manera gráfica el ciclo de vida descrito previamen-

te. Los datos se crean en el ámbito de una organización A (hospital, unidad
médica familiar, consultorio, laboratorio) y es ahı́ donde se aseguran mediante
la creación del SDB. Más adelante, desde el repositorio donde se encuentre di-
cho SDB, los usuarios (especialistas de la salud, sistemas, dispositivos) pueden
acceder a él y únicamente aquellos con los atributos necesarios podrán abrir el
SDB y acceder a los datos en claro. Durante la creación y apertura de SDB,
SDB
Figura 9:Figura 3 Ejemplo

Creación del intercambio
y acceso (apertura)dededatos utilizando
sobres sobres
digitales digitales.
buscables (SDB) en
salud.
los esquemas de paralelismo permiten la viabilidad de implantar este concepto,

puesto que los datos médicos, como las tomografı́as, generalmente ocupan una
cantidad considerable de almacenamiento y, bajo un escenario de big data, la
complejidad en tiempo incrementa considerablemente. El transporte seguro de
los datos sensibles médicos, posible mediante los SDB, permite la distribución
de datos sensibles de forma segura, lo cual es un requerimiento en las normas
oficiales para tratamiento de datos médicos. Los usuarios finales de los datos, que
los recuperan mediante operaciones de descifrado, podrán usarlos en los proce-
sos correspondientes para su análisis y obtención de conocimiento útil mediante
técnicas de ciencia de datos.
7. Retos y Perspectivas para Proteger Datos en el Sector

Salud
Como es sabido, los datos sensibles generalmente demandan servicios de segu-
ridad y de privacidad. Éste es un requerimiento impuesto, incluso, por regulacio-
nes y leyes que varı́an en cada paı́s. En México, la norma oficial NOM-024-SSA3-
2012 establece los objetivos funcionales y funcionalidades que deberı́an observar
los productos de Sistemas de Expediente Clı́nico Electrónico para garantizar la
interoperabilidad, procesamiento, interpretación, confidencialidad, seguridad, ası́
como uso de estándares y catálogos de la información de los registros electróni-
cos en salud. En este sentido, los SDBs son mecanismos que permiten lograr
objetivos en materia de seguridad de datos y que permiten dar cumplimiento a
los requerimientos de seguridad de éstos. Especı́ficamente, la confidencialidad y
control de acceso son esenciales en el manejo, acceso e intercambio de datos en

salud, que se consiguen con el uso de SDB mediante las técnicas criptográficas
que incorporan.
El cifrado usado en los SDBs es de dos tipos: simétrico y basado en atributos.
Ambos enfoques actualmente son suficientemente seguros. El cifrado simétrico
sustenta su seguridad en que el trabajo de un atacante para vulnerarlo es expo-
nencial respecto al tamaño de las llaves usadas. En la actualidad, se considera
que una llave de 128 bits es imposible de atacar (en la práctica), dado que el
costo computacional para lograrlo es de 2128 operaciones. Por lo anterior, a una
computadora convencional le tomarı́a centenas de años realizar este trabajo. En
el caso del cifrado basado en atributos, las llaves utilizadas son de un tamaño de
al menos de 3 × 256 bits. En este caso, el costo para un atacante depende de la
dificultad para resolver un problema matemático con un costo asociado de 2256
operaciones en una computadora convencional, pero la llave involucra al menos
tres componentes de 256 bits.
Sin embargo, desde hace algunos años se vienen teniendo avances significa-
tivos en cómputo cuántico. Incluso, algunas empresas como Google han decla-
rado haber alcanzado ya la supremacı́a cuántica, esto es, haber logrado diseñar
una computadora que resuelve problemas que una computadora convencional no
habrı́a podido resolver. La computación cuántica es ahora la mayor amenaza a
las soluciones de seguridad de datos basadas en algoritmos criptográficos, como
lo son los SDBs. Aunque por ahora no existe una computadora cuántica con el
suficiente poder de cómputo para atacar a los sistemas de cifrado como los que se
usan en un SDB, se estima que en un futuro cercano, en 2030 según expertos [8],
se cuente con dicha capacidad. El impacto en la seguridad del cifrado simétrico
no será tan alto como lo será para el cifrado basado en atributos y para otros
tipos de cifrado que basan su seguridad en la dificultad de resolver problemas
matemáticos, ya que el poder de cómputo cuántico podrá resolver dichos pro-
blemas. Por ello, los mecanismos de seguridad que se apoyan en el cifrado, como
los SDB, deben fundamentar su seguridad en una criptografı́a postcuántica [3],
misma que ya se viene desarrollando desde 2014.
Existe un ataque llamado harvest now, decrypt later, que en español literal-
mente se traduce como colecta datos cifrados ahora, descı́fralos después. Esto es,
los datos cifrados, al ser ilegibles, aunque estén disponibles para un atacante, no
tienen ninguna utilidad para dicho atacante. Pero el atacante podrı́a recolectar-
los ahora y, cuando se tenga ya una computadora cuántica con suficiente poder
computacional, descifrar esos datos recolectados. Por ejemplo, en la Figura 9, si
un atacante (como el proveedor del servicio de almacenamiento) hace un respal-
do de todos los SDBs, más adelante, con la ayuda de una computadora cuántica,
éste podrı́a abrir todos esos SDBs y, por lo tanto, tener acceso a los datos que,
para ese entonces, pudieran resultar de alguna utilidad. Por ejemplo, los SDBs
asociados a altos mandos militares o polı́ticos de hoy podrı́an revelarse en un
futuro cercano (8 años aproximadamente). Cabe destacar que en el ámbito de
la salud se recomienda conservar los datos médicos de una persona (i.e., historia
clı́nica) por al menos 5 años y hasta 15 años, incluso, después de su muerte.
Por tanto, en este capı́tulo los autores afirmamos que uno de los principales
retos para la seguridad de los datos en el sector salud es contar con mecanismos
de seguridad robustos, no solo bajo los modelos de ataque actuales, sino también
para aquellos modelos de ataque que se vislumbran en un futuro no muy lejano.
Por otro lado, si bien los SDBs son ahora eficientes y seguros, solamente cubren
los servicios de confidencialidad, integridad y control de acceso. Sin embargo, es
necesario tener en cuenta que existen otros requerimientos de seguridad en salud,
tales como la trazabilidad. Es muy deseable explorar el desarrollo de métodos
efectivos que pudieran garantizar estos servicios, como puede ser la incorporación
adecuada de tecnologı́as disruptivas como Blockchain [16].
8. Conclusiones
En este capı́tulo hemos introducido el concepto de sobres digitales con capa-

cidades de búsqueda (SDB). Se trata de una abstracción que permite garantizar
dos servicios de seguridad principales: la confidencialidad y el control de acceso
a datos sensibles. Por ello, los SDBs son idóneos para proteger la seguridad y
privacidad de datos médicos. Al estar basados en dos capas criptográficas, una
fundamentada en el cifrado simétrico (rápido para cifrado) y otra en el cifrado
basado en atributos (efectivo para la distribución de llaves y el control de acceso
criptográfico), los SDBs integran controles de acceso de grano fino aplicables,
incluso, a grandes colecciones de datos, como ocurre en el ámbito del big data
en salud.
La fortaleza de los SDBs está probada y recae en la seguridad de ambas
capas de cifrado. Su eficiencia recae en la efectividad de los patrones de parale-
lismo que se usan en el despliegue de los SDB, bajo la premisa de que existen
recursos de cómputo disponibles (para explotar el paralelismo de datos y de
tareas). La alta seguridad y eficiencia de los SDBs los hacen viables para pro-
veer los requerimientos de confidencialidad y de control de acceso que demanda
el tratamiento de datos sensibles médicos, tal como lo exige la norma mexicana
NOM-024-SSA3-2012. Ante un desarrollo continuo de capacidades de un compu-
tador cuántico, los esquemas de seguridad de datos basados en cifrado se ven
amenazados en el corto plazo. El trabajo futuro se está enfocando en analizar
y desarrollar metodologı́as eficientes para incorporar cifrado postcuántico en el
diseño de los SDBs.
Agradecimientos
Este trabajo forma parte del Proyecto No. 41756 CONACYT - PRONAII
Ciencia de Datos en Salud “Plataforma tecnológica para la gestión, asegura-
miento, intercambio y preservación de grandes volúmenes de datos en salud y
construcción de un repositorio nacional de servicios de análisis de datos de sa-
lud”, financiado por FORDECYT-PRONACES.
Referencias
[1] Aubrey Alston. Attribute-Based Encryption for Attribute-based Authen-
tication, Authorization, Storage, and Transmission in Distributed Stora-
ge Systems. Inf. téc. arXiv:1705.06002v1. Cornell University, 2017. doi:
10.48550/arXiv.1705.06002.
[2] Elaine Barker. Recommendation for Key Management. Part 1: General.
Inf. téc. National Institute of Standards and Technology, 2020. doi: 10.
6028/NIST.SP.800-57pt1r5.
[3] Johannes Buchmann, Kristin Lauter y Michele Mosca. “Postquantum cry-
ptography—state of the art”. En: IEEE Security & Privacy 15.4 (2017),
págs. 12-13. doi: 10.1109/MSP.2017.3151326.
[4] Diana Elizabeth Carrizales-Espinoza, José Luis González-Compeán y Mi-
guel Morales-Sandoval. “Zamna: a tool for the secure and reliable stora-
ge, sharing, and usage of large data sets in data science applications”.
En: 2022 IEEE Mexican International Conference on Computer Science
(ENC). IEEE, 2022. isbn: 978-1-6654-7347-7. doi: 10.1109/ENC56672.
2022.9882938.
[5] Yunling Wang, Jianfeng Wang, Xiaofeng Chen. “Secure Searchable Encry-
ption: A Survey”. En: Communications and Information Networks Vol. 1.
No. 4 (2016), págs. 52-65. doi: 10.11959/j.issn.2096-1081.2016.043.
[6] Cisco Networking Academy. Introduction to Cybersecurity. Inf. téc. Cisco
Systems, Inc., 2016.
[7] Cisco Networking Academy. Cybersecurity Essentials. Inf. téc. Cisco Sys-
tems, Inc., 2017.
[8] Vikas Hassija et al. “Present landscape of quantum computing”. En: IET
Quantum Communication 1.2 (2020), págs. 42-48. doi: 10 . 1049 / iet -
qtc.2020.0027.
[9] Melissa Brigitthe Hinojosa-Cabello. “An Attribute-Based Encryption Sche-
me for Storage, Sharing and Retrieval of Digital Documents in the Cloud”.
Tesis de mtrı́a. Cinvestav, 2020.
[10] Richard Kuhn et al. Introduction to Public Key Technology and the Federal
PKI Infrastructure. Inf. téc. National Institute of Standards and Techno-
logy, 2001.
[11] Badrinarayanan Lakshmiraghavan. Pro ASP.NET Web API Security. Se-
curing ASP.NET Web API. Ed. por Apress Media, LLC. 1.a ed. Springer,
2013. 416 págs. isbn: 978-1-4302-5782-0. doi: 10 . 1007 / 978 - 1 - 4302 -
5783-7.
[12] Elaine Barker, William Barker, Annabelle Lee. Guideline for Implementing
Cryptography in the Federal Government. Inf. téc. National Institute of
Standards and Technology, 2005.
[13] Antonis Michalas. “The Lord of the Shares: Combining Attribute-Based
Encryption and Searchable Encryption for Flexible Data Sharing”. En:
SAC ’19: Proceedings of the 34th ACM/SIGAPP Symposium on Applied
Computing. Association for Computing Machinery, 2018. isbn: 978-1-4503-
5933-7. doi: 10.1145/3297280.3297297.
[14] Praveen Kumar Premkamal, Syam Kumar Pasupuleti y Pja Alphonse.

“Attribute Based Encryption in Cloud Computing: A Survey, Gap Analy-
sis, and Future Directions”. En: Network and Computer Applications 108
(2018), págs. 37-52. doi: 10.1016/j.jnca.2018.02.009.
[15] Conacyt PRONACES. Plataforma tecnológica para la gestión, asegura-
miento, intercambio y preservación de grandes volúmenes de datos en salud
y construcción de un repositorio nacional de servicios de análisis de datos
de salud. PRONACES Salud, FORDECYT 2019-06 CONACyT, proyecto
número 41756. http://adaptivez.org.mx/e-SaludData/. 2022.
[16] Nabil Rifi et al. “Towards using blockchain technology for eHealth data
access management”. En: 2017 fourth international conference on advances
in biomedical engineering (ICABME). IEEE, 2017. isbn: 978-1-5386-1642-
0. doi: 10.1109/ICABME.2017.8167555.
[17] Amit Sahai y Brent Waters. “Fuzzy Identity-Based Encryption”. En: Ad-
vances in Cryptology – EUROCRYPT 2005. Springer Berlin Heidelberg,
2005. isbn: 978-3-540-32055-5. doi: 10.1007/11426639_27.
[18] Douglas Selent. “Advanced encryption standard”. En: Rivier Academic
Journal 6.2 (2010), págs. 1-14.
[19] Vı́ctor Jesús Sosa-Sosa et al. “Protecting Data in the Cloud: An Assess-
ment of Practical Digital Envelopes from Attribute based Encryption”.
En: KDCloudApps 2017. SciTePress, 2017. isbn: 978-989-758-255-4. doi:
10.5220/0006484603820390.
[20] Hui Bin Yin et al. “CP-ABSE: A Ciphertext-Policy Attribute-Based Sear-
chable Encryption Scheme”. En: IEEE Access 7 (2019), págs. 5682-5694.
doi: 10.1109/ACCESS.2018.2889754.
[21] Rui Zhang, Rui Xue y Ling Liu. “Searchable encryption for healthcare
clouds: a survey”. En: IEEE Transactions on Services Computing 11.6
(2017), págs. 978-996. doi: 10.1109/TSC.2017.2762296.
[22] Eduardo Palma Ávila. “Criptografı́a Basada en Hardware”. En: Revista
Seguridad. Cultura de prevención para TI. No. 21. Universidad Nacional
Autónoma de México, jun. de 2014.
Ciencia de Datos en Salud: Minerı́a de Procesos
con Preservación de Privacidad de Datos
Médicos
Heidy M. Marin-Castro1 , Héctor A. De la Fuente-Anaya2 , Miguel

Morales-Sandoval2 , Ana B. Rı́os-Alvarado3 , and Tania Y.Guerrero-Meléndez3
1
Conacyt - Facultad de Ingenierı́a y Ciencias, Universidad Autónoma de
Tamaulipas, México
[email protected]
2
Cinvestav Unidad Tamaulipas, Cd. Victoria, Tamps, México
{hector.delafuente,miguel.morales}@cinvestav.mx
3
Facultad de Ingenierı́a y Ciencias, Universidad Autónoma de Tamaulipas, México
{arios,tyguerre}@docentes.uat.edu.mx
Resumen Diariamente, los sistemas de información generan una gran

cantidad de registros de eventos a partir de la ejecución de procesos. Esta
situación ha incentivado gran interés por parte de las organizaciones por
realizar análisis de estos datos a fin de generar conocimiento que apoye
en la toma de decisiones. La Minerı́a de Procesos, en combinación con
la Preservación de Privacidad de Datos, es una disciplina orientada a
descubrir, monitorear y mejorar el desempeño de los procesos de nego-
cio, garantizando preservar la confidencialidad de los datos sensibles o
personales de eventos producidos por la ejecución de un proceso a partir
de un sistema de información. La gran mayoria de los procesos clı́nicos
relacionados con el diagnóstico, tratamiento y organización de personal
de la salud y de los pacientes requieren de algoritmos que puedan reali-
zar análisis y estudio de sus datos y procesos asegurando la privacidad
y confidencialidad de estos mientras son usados. En este capı́tulo se des-
criben algunas de las caracterı́sticas más relevantes de los procesos en
el dominio de salud, ası́ como la importancia de la Minerı́a de Procesos
como un servicio, y se presenta una estrategia de confidencialidad para
proveer privacidad en los datos de las bitácoras de eventos relacionados
con un proceso clı́nico. Una de las ventajas de la estrategia propuesta es
que permite mantener la utilidad de los datos para las tareas de Minerı́a
de Procesos sin que exista alguna perdida de información o la posibilidad
de revelar a terceros información que se considera confidencial.
Palabras clave: Minerı́a de Proceso · Bitácora de Eventos · Modelo de

Proceso · Confidencialidad · Cifrado · Utilidad de Datos
1. Introducción
En nuestra sociedad actual, el tema de protección y privacidad de datos
ha ganado mucha atención en los últimos años debido a los frecuentes ataques
32 H. Marin-Castro et al.
cibernéticos o filtraciones de datos que comúnmente se presentan contra los sis-

temas de información y las regulaciones relacionadas con Reglamento General de
Protección de Datos (GDPR) de Europa [7]. En general, la privacidad puede ser
descrita como el derecho de las personas a controlar cómo se recopilan, utilizan
y/o divulgan sus datos personales a otros individuos, organizaciones o gobiernos
[21]. La privacidad de los datos se ha vuelto mucho más crı́tica, especialmente
para aquellas empresas que trabajan con datos sensibles, como las organizacio-
nes en el sector salud. Los proveedores de atención médica deben asegurarse de
administrar adecuadamente los datos de los pacientes para crear una cultura de
confianza y transparencia mientras cumplen con las estrictas normas legales y
de privacidad de datos. La privacidad de los datos en el cuidado de la salud está
en constante evolución, con leyes y regulaciones continuamente actualizadas. De
esta forma, los pacientes obtienen la privacidad de datos que esperan. Mientras
que ha habido mucha investigación sobre lo que constituye la privacidad de datos
y su importancia en los sistemas de información en el sector salud [14], [3], [13],
[18], existe una clara brecha en la investigación sobre privacidad en el campo de
la Minerı́a de Procesos (MP), la cual se centra en el estudio de los procesos de
negocio descritos como un conjunto de actividades interrelacionadas y desem-
peñadas por un grupo de participantes para lograr un objetivo de negocio. Esta
disciplina conecta técnicas de la Ciencia de Datos y de la Ciencia de Procesos
para llevar a cabo tareas de descubrimiento, verificación de la conformidad y me-
jora de los procesos de negocio a partir de extraer conocimiento de colecciones
de eventos llamadas bitácoras de eventos [1].
La MP ha evolucionado a través de los años. Al inicio, los algoritmos y

herramientas de MP fueron desarrolladas por grupos de investigación [2] y pau-
latinamente han sido utilizados por la industria a través del análisis y estudio
de casos y proyectos. Actualmente, MP se ha convertido formalmente en una
disciplina ante la IEEE en el 2011 [1], cuyo objetivo principal es el de contribuir
a mejorar el desempeño de los procesos de las organizaciones, a fin de descubrir
su verdadero comportamiento, proporcionando información de lo que se está rea-
lizando bien, diagnosticando problemas y sugiriendo automáticamente acciones
o medidas correctivas o de mejora del proceso. Para ello, se apoya en dos de
los elementos medulares que sirven de entrada a la mayorı́a de los algoritmos de
MP: las bitácoras de eventos y los modelos de proceso. Por un lado, las bitácoras
de eventos son creadas a partir de la ejecución de los procesos de negocio dispo-
nibles a través de sistemas de información de las organizaciones. Cada evento en
la bitácora corresponde a una actividad o tarea que forma parte del proceso de
negocio realizada por algún participante del proceso, y un conjunto de eventos
conforma un caso o instancia. Por ejemplo, en la Tabla 1 se muestran tres ca-
sos y siete eventos relacionados con las actividades de un proceso en el dominio
de salud. Los eventos están conformados por diversos atributos: una estampa
de tiempo (periodo de tiempo en que se ejecutó dicho evento), un nombre de
la actividad ejecutada, un costo (representa el costo tomado por la actividad
asociada al evento), un recurso o participante (rol o nombre de la persona que
llevó a cabo dicho evento), y nombre del paciente. Cada instancia corresponde
Minerı́a de Procesos en Salud 33
a una traza, por ejemplo, la secuencia de actividades {Registro, Triaje, Examen

de Sangre} en la Tabla 1 representa una traza sobre la atención a un paciente,
en este caso el paciente de nombre Brenda.
Tabla 1: Ejemplo del segmento de una bitácora de eventos del dominio de salud.
Id Caso Estampa de Tiempo Actividad Costo Recurso Paciente
1 01-01-2018 15:20:15 Registro 100 Pedro Brenda
1 01-01-2018 15:22:02 Triaje 50 Ana Brenda
1 01-01-2018 15:25:43 Ex. sangre 800 Julio Brenda
2 01-01-2018 15:43:08 Registro 100 Jorge Isidro
2 01-01-2018 15:43:50 Rayos X 500 Pedro Isidro
3 01-01-2018 15:46:27 Registro 100 Pedro Marta
3 01-01-2018 15:48:14 Triaje 50 Ana Marta
Por otro lado, un modelo de proceso puede verse como la representación

abstracta y gráfica de las actividades llevadas a cabo por un proceso de una
organización. Existen diversos lenguajes de notación de los modelos de procesos,
siendo el estándar de Modelado y Notación de Procesos de Negocio (BPMN) [8]
uno de lenguajes más usados. Un ejemplo sencillo de un modelo de proceso
BPMN en el área de salud sobre la atención médica de un paciente puede verse
en la Figura 1. El proceso comienza con la actividad Registrar al paciente, segui-
do por las actividades paralelas Registro de signos vitales y Recolectar sı́ntomas,
seguida por Triaje, es decir, actividades que se ejecutan en cualquier orden. Des-
pués, se realiza la actividad de Actualización del expediente médico y se crean
dos caminos alternativos con las actividades Hacer prueba de sangre y Realizar
análisis de hemoglobina, donde alguna de ellas es ejecutada. Los dos sı́mbolos en
forma de diamante con el signo ’+’ adentro denotan compuertas paralelas. El
primero corresponde a una compuerta paralela de división comenzando con dos
ramas concurrentes y el segundo es la compuerta de la unión. Los dos sı́mbolos
en forma de diamante con el signo ’X’ adentro denotan compuertas exclusivas,
es decir, se tienen caminos alternativos. En el modelo de proceso, el evento ini-
cial (mostrado como un cı́rculo rojo) es activado por el paciente a partir de su
llegada y termina con un evento final (mostrado por un cı́rculo blanco). Duran-
te la ejecución del proceso en salud pueden intervenir diferentes actores, como
personal de salud (médicos, enfermeras, asistentes, etc.) y pacientes, realizando
una o varias actividades del proceso.
1.1. Requerimiento de confidencialidad

Tanto los modelos de procesos como las bitácoras de eventos son una valio-
sa fuente de información que permite identificar el comportamiento real de un
proceso y no únicamente una vista idealizada. Sin embargo, en un dominio de
estudio como el de salud, el trabajar con bitácoras con datos de eventos sensibles,
Recolectar Hacer Prueba

Triaje
Sşntomas de Sangre (f)
(c)
(b)
Registrar Actualización
Paciente de Expediente
(a) Médico (e)
Registro de Realizar
Signos Vitales Análisis de
(d) Hemoglobina (g)
Figura 1: Modelo de proceso BPMN del seguimiento de pacientes.
ası́ como la falta de confianza entre los participantes que ejecutan un proceso,
inspira a la MP a desarrollar y utilizar métodos seguros de los datos de eventos
que garanticen la confidencialidad de éstos. Sin embargo, las investigaciones que
se han reportado en la literatura sobre tareas de MP pocas veces consideran
cuestiones de confidencialidad de los datos, siendo éste un problema de gran
relevancia, principalmente en dominios donde es necesario garantizar seguridad
y privacidad de los datos.
En MP, la confidencialidad de las bitácoras de eventos no se puede lograr
únicamente cifrando los datos; es necesario contar con mecanismos de seguridad
y privacidad adecuados, de forma que las tareas de descubrimiento, validación de
conformidad y mejora de procesos no sean afectadas y puedan seguir realizándo-
se. Uno de los problemas comunes al intentar únicamente de anonimizar algunos
atributos o registros de eventos es la posibilidad de vincular los eventos a un
caso especifico e identificar atributos iguales. Esta situación de vinculación pue-
de ocasionar que se descubra la identidad del registro. Por ejemplo, suponiendo
que se tiene una bitácora de eventos de pacientes de un hospital con algunos
atributos pseudo anonimizados (nombre del paciente, actividad, empleo) y un
atacante desea conocer la enfermedad de cierto paciente del cual únicamente
conoce su edad y algunas de las fechas en las que visitó el hospital en un perı́odo
de tiempo determinado. Al identificar esta información en la bitácora de eventos
puede inferir los eventos correspondientes de este paciente y, ası́, poder cono-
cer su enfermedad. En este escenario se presenta un problema de ataque a la
privacidad en los datos de los registros de eventos a partir de la vinculación de
información.
Muchas organizaciones en salud son conscientes de la necesidad de gestionar
y mejorar sus procesos, los cuales constantemente están evolucionando y cam-
biando dinámicamente. Algunos de los trabajos de investigación reportados en la
literatura [17], [4], [11], [20], [16], [12] sobre la MP en salud, han identificado que
aún no se cuenta con soluciones prácticas capaces de adaptarse a los diferentes
entornos de los procesos en salud, los cuales carecen de mecanismos que garanti-
cen la seguridad de las bitácoras de eventos construidas. En este sentido, resulta
importante desarrollar y mejorar los algoritmos de MP para trabajar con datos
sensibles de acuerdo con las normas internas o regulaciones externas establecidas
por instituciones médicas sin que exista algún riesgo de confidencialidad en los
datos.
1.2. Objetivo y organización de este documento

En este documento se describen algunas de las caracterı́sticas más relevan-
tes de los procesos de negocio en el sector salud y se presenta una Estrategia
de Confidencialidad para la Bitácora de Eventos (ECBE) basada en métodos
criptográficos (haciendo uso de cifrado determinista, ası́ como de técnicas de
anonimización) sin perder la utilidad de los datos para su uso en algoritmos de
Minerı́a de Procesos. Esta estrategia construye una bitácora de eventos segura
capaz de ser usada en tareas como el descubrimiento de procesos. La bitácora de
eventos cifrada puede ser compartida por el equipo multidisciplinar que ejecuta
el proceso sin que se comprometa la privacidad de los datos y el cumplimiento
de las regulaciones, debido a que los participantes del equipo no podrán deducir
información que no tenga que ver con la bitácora o el modelo de proceso cifrado.
El resto de este capı́tulo se encuentra organizado de la siguiente forma: en
la Sección 2 se presentan algunas de las caracterı́sticas más relevantes de los
procesos de negocio en el dominio de la salud; en la Sección 3 se describe un
escenario de las tareas principales, uso y explotación de la MP como servicio; en
la Sección 4 se presenta una descripción de la estrategia de confidencialidad de
la bitácora de eventos propuesta; en la Sección 5 se muestran los detalles de la
experimentación y resultados obtenidos; finalmente, en la Sección 6 se presentan
las conclusiones y trabajo futuro.
2. Procesos de negocio en salud

Uno de los intereses latentes de las organizaciones y, particularmente, en el
sector salud consiste en aplicar MP para conocer la trayectoria de diferentes
pacientes desde el momento de su ingreso hasta su alta hospitalaria. Cada visita
de un paciente a un hospital constituye una instancia de proceso y los eventos
individuales de cada caso se pueden obtener a partir del Sistema de Información.
Este último normalmente registra información sobre las actividades logı́sticas y
de tratamiento realizadas para pacientes especı́ficos y el personal del hospital que
los realizó. Además, una parte de un proceso en salud puede ser las interaccio-
nes con otras instituciones asistenciales y la solicitud de documentación médica
previa. Por lo tanto, algunos de estos datos pueden ser compartidos sobre los
lı́mites de la organización o entre otras organizaciones y, ası́, realizar MP con
éstos.
Tı́picamente, los procesos en salud se caracterizan por presentar altos niveles
de variación debido a una vasta diversidad de actividades que pueden llevarse
a cabo de forma secuencial o paralela por distintos participantes del proceso.
Normalmente, los algoritmos de MP en salud pueden ser apoyados por guı́as y
protocolos médicos para dar una referencia del orden de las actividades a se-
guir dentro del proceso. Sin embargo, en ocasiones los procesos en salud deben
considerar situaciones extraordinarias o de emergencia no previstas, que no ne-

cesariamente corresponden con el orden establecido en el proceso, por lo que en
la mayorı́a de los casos el flujo de ejecución de las actividades en el proceso no
se cumple adecuada o completamente de acuerdo con el orden previsto.
Los procesos de salud son llevados a cabo por un equipo multidisciplinar
(médicos, enfermeras, especialistas, asistentes, etc.), quienes, de manera autóno-
ma e independiente, ejecutan una o varias actividades del proceso y toman deci-
siones sobre determinadas tareas complejas sin apegarse completamente al pro-
ceso clı́nico establecido y sin limitarse al acceso de la información sensible que
pueden manejar. La sensibilidad de los datos es un tema de gran importan-
cia que necesita constantemente tomarse en cuenta, ya que los datos podrı́an
incluir información tal como la condición médica actual del paciente, sus co-
morbilidades, tratamientos e información personal que no deberı́a ser revelada
a ninguna entidad externa o interna que no cuente con un acceso o permiso
necesario. En este escenario, las bitácoras de eventos obtenidas a partir de la
ejecución de un proceso en salud deberı́an ser cuidadosamente manejadas de-
bido a la confidencialidad, privacidad, uso y almacenamiento de la información
que éstas contienen. Además, el riesgo de privacidad se incrementa con el uso de
proveedores de servicios externos, como la nube, para delegarle el costo compu-
tacional y de almacenamiento asociado con el uso de algoritmos, como los de
MP, y de almacenamiento de las bitácoras de eventos. Sin embargo, las técnicas
clásicas de MP no están preparadas para lidiar con problemas relacionados con
la confidencialidad de las bitácoras de eventos dentro de un ambiente de trabajo
multidisciplinario, ası́ como la externalización de las bitácoras de eventos para
tareas de MP en la nube.
3. La Minerı́a de Procesos como servicio
A partir de la MP, muchas organizaciones pueden identificar cuellos de bo-

tella, desviaciones, anticipar y diagnosticar problemas de rendimiento y cumpli-
miento mediante el uso de las bitácoras de eventos y los modelos de procesos.
Particularmente, las técnicas MP pueden ser agrupadas en tres tareas principa-
les:
1. El descubrimiento de modelos de procesos tiene por objetivo descubrir

automáticamente el modelo del proceso asociado a los eventos almacenados
en la bitácora de eventos obtenidos a partir de la ejecución de un sistema de
información, es decir, construye el modelo de proceso tomando como entrada
la bitácora de eventos;
2. La verificación de conformidad consiste en reproducir cada una de las
instancias o trazas contenidas en la bitácora de eventos en el modelo de pro-
ceso para comprobar si lo que se tiene registrado en la bitácora corresponde
con la ejecución y orden de las actividades que se muestran en el modelo de
proceso y viceversa; a partir de esta tarea es posible identificar desviaciones
que pueden ocurrir en el proceso o en su correspondiente bitácora de eventos;
3. La mejora del proceso se enfoca en mejorar el desempeño de los procesos,

ya sea cambiando o extendiendo el modelo previo construido.
Con el auge del Big Data, diariamente se generan grandes cantidades de

datos de eventos a partir de la ejecución de procesos de distintos dominios de
los sistemas de información de las organizaciones, lo que hace necesario contar
con técnicas de MP disponibles como un servicio para delegarles tareas de des-
cubrimiento, conformidad y mejora. En este escenario, los datos (bitácoras de
eventos) dejan de estar bajo el control del propietario del proceso de negocio y
pueden ser accedidos por el proveedor del servicio, lo que puede ocasionar un
riesgo de confidencialidad.
La privacidad se centra en el uso y el manejo de los datos personales de los
individuos, ası́ como las polı́ticas que garantizan que la información personal
de los usuarios se recopile, comparta y utilice de manera correcta [19]. Uno de
los enfoques más usados para garantizar la confidencialidad en la bitácora de
eventos sin perder utilidad en los datos, es el cifrado, el cual transforma un
texto legible en texto ilegible y viceversa, utilizando sus respectivas claves de
cifrado y descifrado. A continuación se describe la estrategia de confidencialidad
propuesta.
4. Estrategia de Confidencialidad de la Bitácora de

Eventos
La Estrategia de Confidencialidad para la Bitácora de Eventos (ECBE) des-
crita en este trabajo está basada en métodos criptográficos y técnicas de anoni-
mización. Esta estrategia asegura la confidencialidad en los datos de la Bitácora
de Eventos, ya que estos se transforman a un formato ilegible que no puede ser
interpretado por los usuarios. La confidencialidad de los datos permite que la
bitácora sea compartida con un servidor externo, como la nube, para llevar a
cabo tareas de MP sin que se pueda revelar información que no esté relacionada
con la tarea de descubrimiento del proceso de negocio cifrado. ECBE se asegura
de preservar la utilidad de los datos en la Bitácora de eventos mediante técni-
cas de cifrado determinista, es decir, siempre se genera el mismo texto cifrado
para un texto plano y una clave dados, lo cual mantiene la diferenciación en los
datos para poder descubrir el modelo del proceso. El escenario de trabajo de la
estrategia ECBE se compone de dos entornos, privado y externo (ver Figura 2),
donde la bitácora de eventos puede moverse de un entorno privado (seguro) a
un entorno externo (inseguro) en su versión cifrada (BE’). Una vez que el algo-
ritmo de descubrimiento de modelos de proceso recibe como entrada una BE’, el
modelo resultante de esta tarea es un modelo de procesos cifrado (MP’) del cual
no se puede extraer información del contexto del proceso de negocio en estudio.
El objetivo del uso de los entornos en la ECBE es garantizar la protección y
determinar los niveles de seguridad que se tendrán en los registros que se tienen
Figura 2: Entornos de seguridad considerados en ECBE.
en las bitácoras. En el entorno externo se protege a la bitácora de eventos de

analistas externos del proceso y de cualquier otro individuo que requiera hacer
uso no permitido de la misma.
La bitácora de eventos cifrada (BE’) evita cualquier riesgo de fuga de in-
formación que pueda ocurrir, aunque el atacante conozca el contexto en el que
ocurre el proceso de negocio. ECBE asegura la bitácora de eventos considerando
sus atributos, como puede verse en el ejemplo de la Figura 3, donde se presentan
eventos que contienen atributos que almacenan valores del tipo numérico, texto
o fecha. Comúnmente, la estrategia ECBE se enfoca en proteger los atributos
más relevantes para la tarea de descubrimiento de procesos, como los que se
presentan en la Figura 3 (estampa de tiempo, actividad, recurso, costo).
La estrategia de confidencialidad ECBE se compone de cuatro etapas (ver
Figura 4), las cuales se enfocan en proteger los datos de los atributos de la
bitácora de eventos e información que se puedan derivar de ésta. A continuación
se describen cada una de las etapas.
Etapa 1. Filtrado y modificación de la entrada. Esta etapa consiste en

preparar los datos relevantes para el análisis deseado. Incluye las siguientes ac-
tividades:
1. A partir de la bitácora de eventos 𝐿 en formato de tabla bidimensional, se

retiran los atributos que son irrelevantes al análisis deseado (datos no sensi-
bles). 𝐿 está conformado por una serie de trazas de la forma (𝑎1 , 𝑎2 , · · · , 𝑎𝑛 ),
donde 𝑎𝑖 representa una actividad. Si la traza se repite k veces, se indica
como (𝑎1 , 𝑎2 , · · · , 𝑎𝑛 )𝑘 .
Atributos mínimos necesarios para el

descubrimiento del modelo del proceso
ID caso Estampa de tiempo Actividad Recurso Costo

1 01-01-2018 15:20:15 Registro Paolo 1000
1 01-01-2018 15:22:02 Comprueba-Vacantes Frank 100
1 01-01-2018 15:25:43 Veriﬁca-Documentos Paolo 50
Eventos 2 01-01-2018 15:43:08 Registro Monica 1000
2 01-01-2018 15:43:50 Comprueba-Vacantes Joey 100
3 01-01-2018 15:46:27 Registro Frank 1000
3 01-01-2018 15:48:14 Veriﬁca-Documentos Frank 50
Atributo tipo númerico

Atributo tipo texto
Atributo tipo fecha
Figura 3: Atributos tı́picos de una BE.
2. Se realiza un filtrado de trazas removiendo de la bitácora de eventos aque-

llas trazas con menor frecuencia de acuerdo a un umbral 𝜃. Los casos que
formen la misma traza se agrupan, de esta manera se forma un conjun-
to de trazas únicas. Por ejemplo, sea 𝐿 una bitácora de eventos con 𝐿 =
{(𝑎, 𝑏, 𝑐, 𝑑, 𝑒, 𝑓 )10 ,(𝑎, 𝑏, 𝑒)8 , (𝑎, 𝑐, 𝑏, 𝑑, 𝑓, 𝑒)20 ,(𝑎, 𝑐, 𝑒, 𝑓 )4 , (𝑎, 𝑐, 𝑓, 𝑐, 𝑒)15 }, y 𝜃 =
10. Después del filtrado se tendrı́a 𝐿′ = {(𝑎, 𝑏, 𝑐, 𝑑, 𝑒, 𝑓 )10 , (𝑎, 𝑐, 𝑏, 𝑑, 𝑓, 𝑒 )20 ,
(𝑎, 𝑐, 𝑓, 𝑐, 𝑒)15 }.
Etapa 2. Cifrado del texto en claro. En esta etapa se proporciona confi-

dencialidad sin pérdida de utilidad a los datos de la bitácora. Para mantener
la capacidad de aplicar cálculos matemáticos básicos a los valores numéricos en
la bitácora de eventos, se usa el algoritmo de cifrado homomórfico Paillier [15],
mientras que para datos de tipo texto, se aplica un algoritmo de cifrado deter-
minista AES [5]. Los atributos Id Caso y Estampa de tiempo no son cifrados en
esta etapa; éstos son protegidos mediante técnicas que les ayudan a conservar
su utilidad. La realización de esta etapa se ilustra en la transformación de los
atributos “Actividad ”, “Recurso” y “Costo” de la bitácora de eventos en claro
en la Tabla 1 y la bitácora de eventos cifrada (BE’) en la Tabla 2.
Etapa 3. Conversión a tiempos relativos. En esta penúltima etapa, el atri-

buto “Estampa de tiempo” es modificado a fin de evitar que los periodos de
tiempo de la bitácora de eventos sean identificados. Para ello, se selecciona otra
fecha (que se mantiene secreta junto a las claves de cifrado) para que todos los
eventos sean relativos a ésta. La estampa de tiempo de cada evento en la bitácora
de eventos se sustituye por su diferencia con la fecha secreta seleccionada. En
las Tablas 1 y 2, en el atributo “Estampa de tiempo” se muestra la conversión
1. Filtrar y modificar la 2. Cifrado del texto en 3. Convertir a tiempos 4. Aplicar el

entrada claro relativos método conector
- Remover atributos innecesarios y : Duración del evento

- Agregar nueva columna
casos con poca frecuencia de - Cifrado Determinista en : Estampa de tiempo de
"Actividad Prev."
ocurrencia. atributos categóricos : relativo nivel general
Actividad Actividad Prev.
Actividad Actividad : Estampa de tiempo secreta
registro INICIO
registro hi4U9FcL
triaje registro
consulta Ekzp2w3d - Relativos a nivel general
consulta triaje
registro hi4U9FcL
... - Agregar nueva columna

- Cifrado Homomórfico en "Actividad Sig."
atributos numéricos
Actividad Actividad Sig.
Costo Costo - Relativos a nivel de traza registro triaje
50 4857394
triaje consulta
100 6601291
consulta FINAL
5130291 ...
50
Figura 4: Etapas de la estrategia ECBE.
realizada.
Etapa 4. Aplicación de método conector. La última etapa consiste en apli-

car un método que permite de forma segura obtener y extraer la estructura de
un grafo dirigido a partir de la bitácora de eventos cifrada (BE’). Esta estructura
sirve de entrada de muchos de los algoritmos de MP. En esta misma etapa se
realiza la reconstrucción de la bitácora de eventos original una vez que se cuen-
te con las claves de descifrado y los valores de fecha relativos. Las actividades
consideradas en el método conector son las siguientes:
1. Se agrega el atributo llamado “Actividad Prev.”, el cual indica la actividad

previa a cada evento en la bitácora de eventos. Esto permite identificar cuáles
actividades están directamente conectadas. En el caso del primer evento de
cada traza, éste tendrá una actividad previa artificial “Start” cifrada con los
mismos parámetros con los que fue cifrado el atributo “Actividad ”.
2. Se asegura la información contenida en el atributo “Id Caso” para no per-
mitir el agrupamiento de eventos en trazas, manteniendo la posibilidad de
recrear la bitácora de eventos original. Esto es realizado dando a cada even-
to un ID aleatorio (“ID”) e indicando el ID previo (“ID P.”). Estas nuevas
columnas en BE’ permiten identificar el evento siguiente a nivel de traza. El
“ID P.” de la actividad inicial en una traza siempre será 0.
3. Enseguida, los atributos “ID” e “ID P.” se ocultan, ya que son utilizados
solo para reconstruir la bitácora de eventos. Estos se concatenan y se cifran
usando el algoritmo de cifrado determinista AES (igual que en la Etapa 2) y
se agrega como nuevo atributo llamado “Conector ” en la bitácora de eventos.
Tabla 2: Bitácora de eventos de la Tabla 1 con ECBE aplicada.

Estampa de tiempo Actividad Actividad Prev. Recurso Costo Conector
00-00-0000 00:00:42 y7y4PUi2 NM7Jgoum XRCDyLgS 59301 5q8aL2at
00-00-0000 00:01:47 UGdnk8fh y7y4PUi2 hLrq2mYD 46012 KQBindVr
00-00-0000 15:46:27 bvS(28op UGdnk8fh 4hIDYn0q 98744 CKl07FSq
00-00-0000 00:01:47 y7y4PUi2 NM7Jgoum tpwUTcAl 58430 N9a1qeto
00-00-0000 00:03:41 jhg!676 y7y4PUi2 XRCDyLgS 81023 XIQ7ZnqA
00-00-0000 15:20:15 y7y4PUi2 NM7Jgoum XRCDyLgS 59015 M4qAwqqz
00-00-0000 15:43:08 UGdnk8fh y7y4PUi2 hLrq2mYD 42110 z5Zb56jY
4. Posteriormente, se usa el atributo “Estampa de tiempo” para proteger los

valores de tiempo en eventos que cuenten con el mismo “Id Caso”. Éstos se
hacen relativos con respecto a la estampa de tiempo precedida, a excepción
del primer evento de cada traza, el cual se mantiene con el mismo valor. Esto
permite el cálculo de la duración de cada uno de los arcos en un grafo dirigi-
do de seguimiento directo (DFG), pero hace complicado identificar eventos
basándose en la parte temporal en la que ocurrieron.
5. Para finalizar, se retira el atributo “Id Caso” y se desorganiza el orden de
todas las filas y se obtiene como resultado una bitácora de eventos protegida
para el entorno externo (BE’) (ver Tabla 2), capaz de ser usada para descu-
brimiento de procesos basándose en las causalidades de los eventos haciendo
uso de un grafo DFG (generado de “Actividad ” y “Actividad Prev.”).
5. Evaluación de la estrategia ECBE
La estrategia ECBE se implementó en el lenguaje de programación Java,

considerado como un lenguaje de alto nivel que permite expresar los algoritmos
en un nivel más abstracto del lenguaje máquina. ECBE se evaluó usando datos
reales extraı́dos de sistemas ERP (Enterprise Resource Planning) de tres bitáco-
ras de eventos del campo de salud (ver detalles en la Tabla 3) con una clave de
cifrado AES de una longitud de 128 bits. Con estas bitácoras se comprobó que los
modelos de proceso DFG resultantes de las bitácoras de eventos cifradas fueran
iguales a los resultantes de sus versiones en claro. De esta manera se comprueba
que no existe pérdida en la utilidad de los datos al protegerlos con la estrategia
propuesta.
En la evaluación de la estrategia propuesta se consideró el correcto descubri-
miento de los modelos procesos y se comprobó que la solución propuesta permite
obtener modelos con una nula pérdida de precisión, lo que demuestra que la so-
lución propuesta basada en una estrategia criptográfica no produce pérdida de
utilidad en los datos de entrada para los algoritmos de descubrimiento de pro-
cesos.
Tabla 3: Bitácoras de eventos de datos médicos reales.

Nombre No. eventos No. actividades No. trazas
Sepsis Cases [9] 15,214 16 1,050
BPIC11 [6] 150,291 624 1,143
Hospital Billing [10] 451,359 18 100,000
aA1TDhMyfM (3779) 2517

325 337
221 407 DHLBhKOLnM (2931) 1841
10 12 58 138 69 369
13 9 2kkPBQnULj (1171) 178 18 37 52
43 4
1 4 84 28 47 269 21 32 1
Wohescgjyj (10) Pw7EmRpa/W (6) eWDX0GEHl3 (1290) 871 4 20 38 192 19 21
19 52 19 5 5 41 14 10 1
88 53 148 28 zl6frjaiAF (116) 1 13 48 lv0z/V8ko8 (1)
141 55 1 10 11 44 75
20 2 497 29 9 hh812oJMLv (1001) 1 1 50 103 1 279
11 22 43 80 27 11 5 269 1 1
1 17 36 92 45 905 6 YkZjs41trv (1050) 117 3
6 2 4 75 971 5
10 6 FdGvBQbt5A (1051) 2 7 285
1 5 22 14 1
k1gkfv8cMh (741) 30 23 11
35 479
1 9/N6kWXurS (735) 21 2
1 2
GtP3gkQD+6 (1) yBZxqZq+S1 (278)
276
A6gSHksG2l (3)
Figura 5: Modelo de proceso DFG de la bitácora de eventos cifrada Sepsis Cases

resultante de ECBE.
La Figura 5 muestra el modelo descubierto usando la bitácora de eventos

de Sepsis Cases cifrada usando la estrategia ECBE propuesta. Al comparar el
modelo de proceso cifrado con el obtenido del modelo de proceso en su versión en
claro, ambos modelos presentan la misma cantidad de aristas (137) y el mismo
peso en cada una, lo que demuestra que no existe pérdida de utilidad al usar
ECBE. Por lo tanto, el modelo obtenido a partir de la bitácora de eventos cifrada
(BE’) puede convertirse en el modelo que se obtendrı́a usando la bitácora de
eventos (en claro) y las llaves de descifrado correspondientes.
6. Conclusiones
Los procesos en salud representan un gran desafı́o debido a las diversas ca-
racterı́sticas que éstos presentan, como altos niveles de variación, diversidad en
la ejecución y flujo de las actividades de los procesos, trabajo colaborativo de
un equipo multidisciplinar (médicos, enfermeras, especialistas, asistentes, etc),
ası́ como el manejo de datos sensibles. Ésto hace necesario contar con algoritmos
de MP capaces de trabajar con temas de confidencialidad, privacidad, uso y al-
macenamiento de la información, particularmente de las bitácoras de eventos y

modelos de procesos. En este trabajo se describieron algunas de las caracterı́sti-
cas más relevantes de los procesos en salud y se presentó una estrategia llamada
ECBE para garantizar la confidencialidad de la bitácora de eventos de un pro-
ceso de negocio en salud, sin pérdida de su utilidad en tareas de MP. ECBE está
basada en la protección de los campos de una bitácora de eventos usando un
algoritmo de cifrado determinista y técnicas de anonimización para mantener la
diferenciación en los datos a fin de compartirlos con un servidor externo como la
nube y, ası́, poder llevar a cabo tareas de MP sin que se pueda revelar informa-
ción del proceso de negocio. A partir de la bitácora de eventos cifrada resultante
por la estrategia propuesta no es posible relacionar los eventos, permitiendo que
no se descubran trazas o secuencias de eventos, manteniendo la capacidad de
realizar las tareas de MP. Una de las limitaciones de ECBE es que solo permite
la creación de modelos DFG, lo que no permite usar algoritmos de MP basados
en consecuencias. Como parte del trabajo futuro se considera el d esarrollo de
un mecanismo de control de acceso y compartición segura tanto de la bitácora
de eventos como del modelo de proceso para entidades autorizadas.
Referencias
[1] Wil M. P. van der Aalst. Process Mining: Data Science in Action. 2.a ed.
Heidelberg: Springer, 2016. isbn: 978-3-662-49850-7. doi: 10.1007/978-
3-662-49851-4.
[2] Wil M. P. van der Aalst y A. J. M. M. Weijters. “Process mining: a research
agenda”. En: Comput. Ind. 53.3 (2004), págs. 231-244. doi: 10.1016/j.
compind.2003.10.001. url: https://doi.org/10.1016/j.compind.
2003.10.001.
[3] Karim Abouelmehdi, Abderrahim Beni-Hessane y Hayat Khaloufi. “Big
healthcare data: preserving security and privacy”. En: Journal of Big Data
5 (ene. de 2018). doi: 10.1186/s40537-017-0110-7.
[4] Elisabetta Benevento et al. “Evaluating the Effectiveness of Interacti-
ve Process Discovery in Healthcare: A Case Study”. En: Business Pro-
cess Management Workshops. Ed. por Chiara Di Francescomarino, Rem-
co Dijkman y Uwe Zdun. Cham: Springer International Publishing, 2019,
págs. 508-519.
[5] Joan Daemen y Vincent Rijmen. “The Advanced Encryption Standard
Process”. En: The Design of Rijndael: AES — The Advanced Encryption
Standard. Berlin, Heidelberg: Springer Berlin Heidelberg, 2002, págs. 1-8.
isbn: 978-3-662-04722-4. doi: 10.1007/978-3-662-04722-4\_1.
[6] Boudewijn van Dongen. Real-life event logs - Hospital log. 2011. doi: 10.
4121/uuid:d9769f3d-0ab0-4fb8-803b-0d1120ffcf54.
[7] EU General Data Protection Regulation. 2016. Regulation (EU) 2016/679
of the European Parliament and of the Council of 27 April 2016 on the
protection of natural persons with regard to the processing of personal data
and on the free movement of such data, and repealing Directive 95/46/EC
(General Data Protection Regulation) (Text with EEA relevance). 2016.

url: https://eur-lex.europa.eu/eli/reg/2016/679/oj.
[8] Business Process Management Initiative. BPMN Specification - Business
Process Model and Notation. 2005. url: https://www.bpmn.org.
[9] Felix Mannhardt. Sepsis Cases - Event Log. 2016. doi: 10.4121/uuid:
915d2bfb-7e84-49ad-a286-dc35f063a460.
[10] Felix Mannhardt. Hospital Billing - Event Log. 2017. doi: 10.4121/uuid:
76c46b83-c930-4798-a1c9-4be94dfeb741.
[11] Niels Martin et al. “Interactive Data Cleaning for Process Mining: A Case
Study of an Outpatient Clinic’s Appointment System”. En: Business Pro-
cess Management Workshops. Ed. por Chiara Di Francescomarino, Rem-
co Dijkman y Uwe Zdun. Cham: Springer International Publishing, 2019,
págs. 532-544. isbn: 978-3-030-37453-2.
[12] Jorge Munoz-Gama et al. “Process mining for healthcare: Characteris-
tics and challenges”. En: Journal of Biomedical Informatics 127 (2022),
pág. 103994. issn: 1532-0464. doi: https : / / doi . org / 10 . 1016 / j .
jbi.2022.103994. url: https://www.sciencedirect.com/science/
article/pii/S1532046422000107.
[13] Blake Murdoch. “Privacy and artificial intelligence: challenges for protec-
ting health information in a new era”. En: BMC Medical Ethics (ene. de
2021). doi: https://doi.org/10.1186/s12910-021-00687-3.
[14] Sharyl Nass, Laura Levit y Lawrence Gostin. Beyond the HIPAA Privacy
Rule: Enhancing Privacy, Improving Health Through Research. Feb. de
2009. isbn: 978-0-309-12499-7. doi: 10.17226/12458.
[15] Pascal Paillier. “Public-Key Cryptosystems Based on Composite Degree
Residuosity Classes”. En: Advances in Cryptology — EUROCRYPT ’99.
Ed. por Jacques Stern. Berlin, Heidelberg: Springer Berlin Heidelberg,
1999, págs. 223-238. isbn: 978-3-540-48910-8.
[16] Marco Pegoraro et al. “Analyzing Medical Data with Process Mining: a
COVID-19 Case Study”. En: arXiv e-prints, arXiv:2202.04625 (feb. de
2022), arXiv:2202.04625. arXiv: 2202.04625 [cs.DB].
[17] Eric Rojas et al. “Process mining in healthcare: A literature review”.
En: Journal of Biomedical Informatics 61 (2016), págs. 224-236. issn:
1532-0464. doi: https : / / doi . org / 10 . 1016 / j . jbi . 2016 . 04 . 007.
url: https : / / www . sciencedirect . com / science / article / pii / S
1532046416300296.
[18] Sudhakar Sengan et al. “Secured and Privacy-Based IDS for Healthcare
Systems on E-Medical Data Using Machine Learning Approach”. En: In-
ternational Journal of Reliable and Quality E-Healthcare 11 (oct. de 2021),
págs. 1-11. doi: 10.4018/IJRQEH.289175.
[19] H. Smith, Tamara Dinev y Heng Xu. “Information Privacy Research: An
Interdisciplinary Review”. En: MIS Quarterly 35 (dic. de 2011), págs. 989-1015.
doi: 10.2307/41409970.
[20] Zoe Valero-Ramon et al. “Dynamic Models Supporting Personalised Chro-
nic Disease Management through Healthcare Sensors with Interactive Pro-
cess Mining”. En: Sensors 20.18 (2020). issn: 1424-8220. doi: 10.3390/
s20185330. url: https://www.mdpi.com/1424-8220/20/18/5330.
[21] Alan F. Westin. “Privacy And Freedom”. En: Washington and Lee Law
Review 25 (ene. de 1968), págs. 166-170.
[email protected], [email protected],
[email protected], [email protected]
Figura 3. Representación conceptual de un escenario real de salud crítico para la toma de deci-
sio
[10], [11];

[12];

[13];

[14],
[15].
Figura 5. Representación conceptual de un flujo de datos de un sistema de e-salud y/o un sis-
tema de analítica utilizando Muyal-Chimalli para proveer seguridad a los datos.
conceptual del flujo de datos de un sistema utilizando
los servicios de Muyal-Chimalli para proveer seguridad a los datos.
Figura 6
[22], [23]
[24] .
[25], [26]).
[27]
[28]
[31].
[32].
1 El nombre de Nez está inspirado en Nezahualcóyotl, ingeniero de la época precolombina en
México que introdujo diferentes técnicas tales como el uso de estructuras de pilares.
𝑛
𝑛
2 http://adaptivez.org.mx/e-SaludData/
[2] Carroll, N. (2016). Key success factors for smart and connected health software solu-
tions. Computer, 49(11), 22-28.
[17] Rasmussen, S. A., & Jamieson, D. J. (2020). Public health decision making during
Covid-19—Fulfilling the CDC pledge to the American people. New England Journal of
Medicine, 383(10), 901-903.
[18] Sobhy, D., El-Sonbaty, Y., & Abou Elnasr, M. (2012, December). MedCloud:
healthcare cloud computing system. In 2012 International Conference for Internet
Technology and Secured Transactions (pp. 161-166). IEEE.
[19] Abdelazeem, M., Elamin, A., Afifi, A., & El-Rabbany, A. (2021). Multi-sensor point
cloud data fusion for precise 3D mapping. The Egyptian Journal of Remote Sensing
and Space Science, 24(3), 835-844.
[20] Griebel, L., Prokosch, H. U., Köpcke, F., Toddenroth, D., Christoph, J., Leb, I., ... &
Sedlmayr, M. (2015). A scoping review of cloud computing in healthcare. BMC medi-
cal informatics and decision making, 15(1), 1-16.
[21] Zheng, C., & Thain, D. (2015, June). Integrating containers into workflows: A case
study using makeflow, work queue, and docker. In Proceedings of the 8th International
Workshop on Virtualization Technologies in Distributed Computing (pp. 31-38).
[22] Babuji, Y., Woodard, A., Li, Z., Katz, D. S., Clifford, B., Kumar, R., ... & Chard, K.
(2019, June). Parsl: Pervasive parallel programming in python. In Proceedings of the
28th International Symposium on High-Performance Parallel and Distributed Compu-
ting (pp. 25-36).
[23] Chard, R., Babuji, Y., Li, Z., Skluzacek, T., Woodard, A., Blaiszik, B., ... & Chard, K.
(2020, June). Funcx: A federated function serving fabric for science. In Proceedings of
the 29th International symposium on high-performance parallel and distributed compu-
ting (pp. 65-76).
[24] Sanchez-Gallegos, D. D., Gonzalez-Compean, J. L., Carretero, J., Marin, H., Tcher-
nykh, A., & Montella, R. (2022). PuzzleMesh: A puzzle model to build mesh of agnos-
tic services for edge-fog-cloud. IEEE Transactions on Services Computing.
[25] Sánchez-Gallegos, D. D., Galaviz-Mosqueda, A., Gonzalez-Compean, J. L., Villarreal-
Reyes, S., Perez-Ramos, A. E., Carrizales-Espinoza, D., & Carretero, J. (2020). On the
continuous processing of health data in edge-fog-cloud computing by using mi-
cro/nanoservice composition. IEEE Access, 8, 120255-120281.
[26] Das, J., Ghosh, S., Mukherjee, A., Ghosh, S. K., & Buyya, R. (2022). RESCUE: Ena-
bling green healthcare services using integrated IoT‐edge‐fog‐cloud computing envi-
ronments. Software: Practice and Experience.
[27] Mukherjee, A., Ghosh, S., Behere, A., Ghosh, S. K., & Buyya, R. (2021). Internet of
Health Things (IoHT) for personalized health care using integrated edge-fog-cloud
network. Journal of Ambient Intelligence and Humanized Computing, 12(1), 943-959.
[28] Chung, L., & Prado Leite, J. C. S. D. (2009). On non-functional requirements in soft-
ware engineering. In Conceptual modeling: Foundations and applications (pp. 363-
379). Springer, Berlin, Heidelberg.
[29] Zhang, X., Liu, S., Chen, X., Wang, L., Gao, B., & Zhu, Q. (2018). Health information
privacy concerns, antecedents, and information disclosure intention in online health
communities. Information & Management, 55(4), 482-493.
[30] Keshta, I., & Odeh, A. (2021). Security and privacy of electronic health records: Con-
cerns and challenges. Egyptian Informatics Journal, 22(2), 177-183.
[31] Mell, P., & Grance, T. (2011). The NIST definition of cloud computing.
[32] Ranabahu, A., Anderson, P., & Sheth, A. (2011). The cloud agnostic e-science analysis
platform. IEEE Internet Computing, 15(6), 85-89.
[33] Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara, M., Montesi, F., Mustafin, R.,
& Safina, L. (2017). Microservices: yesterday, today, and tomorrow. Present and ulteri-
or software engineering, 195-216.
[34] Sharma, P., Chaufournier, L., Shenoy, P., & Tay, Y. C. (2016, November). Containers
and virtual machines at scale: A comparative study. In Proceedings of the 17th interna-
tional middleware conference (pp. 1-13).
[35] Rad, B. B., Bhatti, H. J., & Ahmadi, M. (2017). An introduction to docker and analysis
of its performance. International Journal of Computer Science and Network Security
(IJCSNS), 17(3), 228.
Xelhua: una plataforma para la creación de
sistemas de ciencia de datos bajo demanda
J. Armando Barrón-Lugo1[0000−0002−9619−8116] , José Carlos

Morı́n-Garcı́a1[0000−0003−1327−4409] ,
José Lui González-Compeán1[0000−0002−2160−4407] , Ivan
Lopez-Arevalo1[0000−0002−7464−8438]
1
Centro de Investigación y de Estudios Avanzados (Cinvestav) del IPN Unidad
Tamaulipas, Cd. Victoria 87130, Tamaulipas , México
{juan.barron, jose.morin, joseluis.gonzalez, ilopez} @cinvestav.mx
Resumen La ciencia de datos es un conjunto de procesos, técnicas y

métodos cientı́ficos para la extracción de conocimiento de conjuntos de
datos para la toma decisiones. Actualmente, existen múltiples herramien-
tas para extraer información de datos estructurados; no obstante, su uso
puede llegar a ser confuso para usuarios menos experimentados, requerir
recursos de cómputo dedicados, complicadas instalaciones, o la perdida
del control sobre sus datos al usar servicios de proveedores en la nube
(Vendor lock-in). En este trabajo presentamos Xelhua, una plataforma
para la creación de sistemas de ciencia de datos bajo demanda y en-
focada al diseño que permite a usuarios sin amplios conocimientos en
programación realizar análisis de datos estructurados. Xeluha permite
transformar aplicaciones a servicios y, posteriormente, al despliegue au-
tomático de sistemas de ciencia de datos en diferentes infraestructuras
de cómputo bajo demanda, mitigando las dependencias con proveedores
y evitando escenarios de vendor lock-in.
Palabras clave: Manejo de Datos · Ciencia de Datos · Analı́tica de Datos ·
Microservicios · Orquestación de Datos.
1. Introducción
Actualmente estamos viviendo en la era de la conexión de información; el uso

del teléfono móvil, las redes sociales, nuestras computadoras personales, incluso
nuestros coches, todo se encuentra conectado, capturando y almacenando datos
para posteriormente analizarlos y producir información y conocimiento útil que
ayude en la toma de decisiones [12]. Los resultados de esto se pueden observar en
muchos ámbitos de la vida diaria: esa canción recomendada por Spotify, las rutas
alternas para llegar a tu trabajo proporcionada por tu teléfono, el pronóstico del
clima... todo es resultado de un proceso de análisis de grandes cantidades de
datos. Pero, ¿cómo pueden estas aplicaciones procesar tantos datos?
82 J.A Barron-Lugo et al.
Desde el punto de vista tecnológico, el procesar datos no es una tarea sencilla.

Realmente es un conjunto de tareas encadenadas que componen un proceso com-
plejo [6], [3]. Un ejemplo para, inicialmente, comprender la dificultad de analizar
grandes cantidades de datos es el intentar abrir un archivo de datos en el formato
más comúnmente usado, CSV (comma separated values), de 5 GB de tamaño en
una computadora personal. En la mayorı́a de los casos, a menos que se tengan
16 GB o más de memoria RAM, la computadora quedará congelada, incapaz
de abrir el archivo, teniendo como única alternativa presionar el botón de apa-
gado para reiniciarla. Esto se debe a que la computadora no tiene la suficiente
memoria RAM para cargar el archivo. Para mitigar esta situación se requieren
muchos más recursos de cómputo; dependiendo de la complejidad del análisis a
realizar se puede requerir más RAM, CPU, almacenamiento o todos juntos [2].
Para el adecuado suministro de recursos de cómputo que permitan el procesa-
miento de grandes cantidades de datos, se han desarrollado técnicas, estrategias
y herramientas. Sin embargo, para una empresa u organización que no tenga un
enfoque hacia las Tecnologı́as de la Información, el uso de estas herramientas
y estrategias se puede volver todo un reto, desde la compra y mantenimiento
de servidores hasta la instalación y configuración de las aplicaciones a usar. De
hecho, ante tal reto, los planes de crecimiento y operación de la organización se
ven limitados [1].
Conociendo la necesidad de estas organizaciones, empresas como Amazon

o Google ofrecen infraestructura de cómputo ya configurada y han optado por
un modelo de negocios conocido como Software-como-Servicio (Software-as-a-
Service) [8], el cual, a grandes rasgos, consiste en el alquiler de software (progra-
mas, herramientas, etc.) e infraestructura (servidores, discos de almacenamiento)
a las organizaciones, proporcionándoles todo lo necesario para procesar sus da-
tos sin necesidad de instalar software, sin los costos de mantener operativo un
servidor y pagando únicamente por lo que usan. En este sentido, los usuarios
finales y organizaciones ya no deben preocuparse por detalles técnicos de las he-
rramientas, enfocándose únicamente en el análisis de los datos; sin embargo, el
uso de este modelo puede conllevar a generar una dependencia con el proveedor
de servicio. Por ejemplo, pueden ocurrir escenarios en los cuales se acumulen
grandes cantidades de datos en la nube, lo que conlleva a elevados costos de
migración. Otro ejemplo podrı́a ser el acceso, puesto que si no se tiene acceso
a internet, luz o el dominio no se encuentra disponible, el acceso a los datos
es imposible. A este tipo de problemas por la dependencia a un proveedor de
servicio se les conoce como escenarios de vendor lock-in.
En este trabajo presentamos a Xelhua, una plataforma para la creación de

sistemas de ciencia de datos bajo demanda. Esta plataforma está pensada con
el objetivo de permitir a usuarios menos experimentados en el área de las tecno-
logı́as diseñar y materializar, en cualquier infraestructura de cómputo, sistemas
de ciencia de datos para el apoyo a la toma de decisiones, proporcionando un
modelo tecnológico para encapsular aplicaciones existentes, desplegarlas y pro-
veerlas para su uso a usuarios finales. En este sentido, Xelhua permite a los
Xelhua 83
usuarios analizar conjuntos de datos estructurados sin necesidad de programar,

únicamente seleccionando servicios para análisis que se tienen disponibles.
2. Antecedentes
2.1. ¿Qué son los contenedores virtuales?
El modelo de negocio de empresas como Amazon o Google es posible gra-

cias al concepto de virtualización. La forma más conocida de virtualización son
las máquinas virtuales, las cuales consisten en la emulación de la infraestruc-
tura de una única computadora (RAM, CPU, disco duro y sistema operativo)
en una máquina fı́sica [7]. En pocas palabras, las máquinas virtuales permiten
crear de manera virtual una computadora dentro de otra (anfitrión), la cual tie-
ne su propia configuración y sistema operativo. De esta forma, es posible que
en una misma máquina fı́sica puedan existir diferentes máquinas virtuales, cada
una con recursos (RAM, CPU, disco duro y sistema operativo) distintos entre
sı́. Asimismo, es posible ofrecer una máquina virtual como un entorno de ser-
vidor a múltiples usuarios. Dado que las máquinas virtuales son desplegadas
bajo demanda, son portables (ya que al ser virtuales, pueden ser almacenadas
y transportadas como un archivo) y están aisladas unas de otras [13]. Si bien
las máquinas virtuales han sido una piedra angular en el avance tecnológico de
la virtualización y, por ende, de la computación, éstas tienen algunas desventa-
jas, dentro de las que destacan su tamaño y velocidad. Su tamaño, puesto que
a cada una se le debe instalar su propio sistema operativo, lo cual hace a su
representación fı́sica (archivo) muy grande, en el orden de varios GB. Por otro
lado, la velocidad de una máquina virtual no es la misma que la máquina fı́sica
anfitriona, dado que el proceso de virtualización pasa a través de varias capas,
lo cual genera latencia.
Una alternativa a las máquinas virtuales son los contenedores virtuales [10].
Éstos siguen un proceso de virtualización similar, pero omitiendo algunas capas,
lo que permite realizar tareas similares a las máquinas virtuales, pero siendo
más ligeros en tamaño y más rápidos de desplegar. Esta tecnologı́a ha tenido
un auge muy importante en los últimos años, puesto que sus propiedades per-
miten diseñar sistemas muy diversos, adaptables, personalizables y de manera
mucho más sencilla [9]. Por ejemplo, es posible instalar un programa o un sistema
completo dentro de un contenedor virtual, clonarlo y desplegarlo en una compu-
tadora personal, en múltiples servidores o incluso en una infraestructura de nube.
Tanto los contenedores virtuales como las máquinas virtuales permiten conte-
ner programas y aplicaciones, de tal forma que su instalación y configuración se
efectúa una única vez y no cada vez que se despliegue en una computadora o
servidor. Algunos ejemplos de servicios desplegados en contenedores que usamos
de manera habitual son Gmail, Google Maps, OneDrive, Overleaf, Colaboratory,
GitHub, Netflix, Spotify, entre otros. Usualmente, se dice que estas aplicaciones
se ejecutan en la nube, algo que se inició con las máquinas virtuales. No obstan-
te, el uso de máquinas virtuales por parte de empresas proveedoras de servicio
ha ido en decremento en los últimos años. Los proveedores han ido migrando
poco a poco sus sistemas a contenedores virtuales. Esto último debido a todas
las ventajas que proporcionan sobre las máquinas virtuales. Una de las diferen-
cias destacables que es importante mencionar es el consumo energético [4], que
últimamente ha atraı́do mucho la atención por diversos aspectos, el más impor-
tante es el impacto que tiene en la reducción de CO2, lo que, a la par, impacta
en los costos de mantenimiento de la infraestructura y, en consecuencia en el
abaratamiento de los precios hacia el usuario final. Por un lado, los contenedores
virtuales tienen una mejor gestión en los recursos de cómputo que se utilizan en
una máquina fı́sica que su contraparte, las máquinas virtuales, además de que,
al contar con menos capas en la virtualización, tienen una menor cantidad de
procesos en ejecución.
Los contenedores virtuales tienen mucha aplicabilidad en la vida cotidiana;
muchas aplicaciones de software pueden ejecutarse sobre contenedores virtuales
sin que el usuario final lo note. De hecho, los contenedores virtuales están pensa-
dos para, a bajo nivel, realizar diversas tareas sin que el usuario, en el alto nivel,
note cambios en el desempeño de las aplicaciones. Los contenedores virtuales son
especialmente útiles en aplicaciones encadenadas (aplicaciones contenerizadas)
que se ejecutan en la nube. Éstas son aplicaciones “grandes”, cuyos componentes
(“pequeños”) se ejecutan en diferentes contenedores virtuales separados. Estas
aplicaciones se apegan a un flujo de trabajo con productos parciales y finales,
los cuales se pueden usar en otros procesos como productos parciales o como
producto final deseado. Ésto puede verse como un Modelo de procesamiento
𝐸𝑇 𝐿, Extraer, Transformar y Cargar (𝐸𝑇 𝐿 𝐸𝑥𝑡𝑟𝑎𝑐𝑡, 𝑇 𝑟𝑎𝑛𝑠𝑓 𝑜𝑟𝑚, 𝐿𝑜𝑎𝑑), el
cual realiza la adquisición de datos y su posterior transformación ejecutando
alguna operación o modificación a los datos y su transferencia a un repositorio
destino, el cual puede ser otro contenedor virtual [5]. Por ejemplo, aplicaciones
para la limpieza de valores nulos o vacı́os en un dataset, detección de outliers,
cálculos estadı́sticos, visualización de datos, etc. Un tipo de estas aplicaciones
son aquellas dedicadas al análisis de datos, también denominadas herramientas
de analı́tica de datos. Los procesos de análisis de datos en la nube se realizan
utilizando tecnologı́as de virtualización y herramientas de analı́tica, encapsulan-
do estas últimas en contenedores virtuales y otorgándole acceso a los usuarios
finales a éstas mediante una interfaz elegante.
2.2. Plataformas de análisis de datos en la nube
Aun teniendo recursos de cómputo disponibles, el análisis en grandes volúme-

nes de datos es un proceso complejo. Para un usuario común puede resultar
agobiante el tener que aprender a utilizar múltiples herramientas, conceptos y
tecnologı́as de contenedores virtuales, en adición a los conceptos y herramientas
de análisis de datos. Las plataformas de análisis de datos son una opción viable
para mitigar estos retos. Una de las principales razones para realizar análisis de
datos en plataformas en la nube es la facilidad de uso que brindan [14]. Muchas
veces las organizaciones no tienen ni el recurso financiero, técnico, ni tiempo
Xelhua 85
para efectuar todo el trabajo de bajo nivel que conlleva configurar e instalar
aplicaciones de análisis de datos. Si bien estas plataformas facilitan y flexibi-
lizan la realización de tareas de análisis de datos, su utilización no está libre
de inconvenientes. El empleo continuo de estas plataformas puede generar una
dependencia a ellas (vendor lock-in), lo que conlleva a problemas a futuro para
las organizaciones [11]. Por ejemplo, si una organización tiene sus datos y sis-
temas en la nube de un proveedor y si este proveedor tiene algún fallo en su
dominio (p. ej. no se puede acceder desde su URL), la organización no podrá
acceder a sus datos. También, si la cantidad de datos que la organización tiene
en la plataforma de análisis es muy grande, los costos de trasladar los datos a
la plataforma de otro proveedor o a los servidores de la propia empresa podrı́an
resultar muy altos. Este tipo de escenarios deben ser tomados muy en cuenta
por las organizaciones, puesto que, si bien, en un inicio, la facilidad de proce-
samiento de datos en la nube es muy atractiva, en un futuro puede interrumpir
drásticamente la continuidad de la operación de una organización.
3. Xelhua, una plataforma de ciencia de datos basada en

contenedores virtuales
Considerando las limitantes que se presentan en un escenario de vendor lock-

in, en Cinvestav Tamaulipas hemos trabajado en el desarrollo de Xelhua, una
plataforma en la nube para el análisis de datos. Xelhua aprovecha la tecnologı́a
de contenedores virtuales para el procesamiento y análisis de datos en múltiples
recursos de cómputo, todo de manera transparente para el usuario final y sin
depender de un proveedor de servicios especı́fico.
3.1. Principios de diseño
Xelhua está basado en un conjunto de modelos matemáticos y esquemas

tecnológicos desarrollados por nosotros mismos, que permiten diseñar soluciones
de procesamiento de datos sin preocuparse por la infraestructura subyacente
donde se ejecute la plataforma, de tal manera que puede ser desplegada en
una computadora personal (el edge), en un conjunto de servidores (fog ), en la
nube (cloud ), o en las tres opciones, a la vez, de manera conjunta. En Xelhua
pueden existir múltiples aplicaciones y herramientas para procesar datos, cada
una encapsulada y aislada de las otras en contenedores virtuales. Mediante la
plataforma, es posible crear flujos de procesamiento (pipelines) en forma de grafo,
uniendo entre sı́ las aplicaciones requeridas (ver Figura 1).
Xelhua está diseñado con base en el modelo de procesamiento ETL. Este
modelo considera que el procesamiento de datos se realiza en 3 etapas: Extrac-
ción, Transformación y Carga. Primeramente, los datos se extraen (E) desde una
fuente; posteriormente, pasan a una etapa de transformación (T) por medio de
algún proceso, aplicación o sistema y, finalmente, se cargan y almacenan (L) los
Figura 1: Panorama de actividades posibles de realizar con Xelhua.
resultados en un resumidero de datos (ej. una carpeta). En este sentido, pode-

mos ver el proceso de transformación de los datos como si de una caja negra
se tratase: un conjunto de datos entra a la caja negra, los transforma y produ-
ce resultados. Siguiendo este modelo, diseñamos para Xelhua entidades para el
procesamiento de datos a las cuales denominamos ABox. Los ABox tienen como
función la abstracción de aplicaciones necesarias para la transformación de datos
(por ejemplo, el movimiento de datos, el monitoreo, etc.) en una sola entidad
que funcione como una caja negra, para que, posteriormente, pueda ser utilizada
como bloque de construcción para la creación de sistemas de ciencia de datos.
En otras palabras, los Abox permiten encapsular aplicaciones para su consumo
como un servicio. Como se puede apreciar en la Figura 2 mediante el uso de
contenedores virtuales, los ABox encapsulan un conjunto de elementos entre los
cuales se encuentran módulos de control de Xelhua, archivos de configuración,
interfaces de entrada y salida para la comunicación con otros ABox, las aplicacio-
nes a encapsular y las dependencias y librerı́as necesarias para que la aplicación
funcione. Por ejemplo, si la aplicación está desarrollada con el lenguaje de pro-
gramación Python, las dependencias serı́an todas aquellas librerı́as necesarias
para ejecutar Python. Una vez que una aplicación se encuentra encapsulada en
una ABox, se considera un servicio, de tal modo que los usuarios finales pueden
invocarlo para la construcción de sistemas de ciencia de datos. En este sentido,
todas las aplicaciones encapsuladas en ABox conforman un repositorio de servi-
cios disponible para usuarios finales. De esta manera, los desarrolladores pueden
encapsular aplicaciones para la transformación y análisis de datos y compartirlos
en lı́nea con los usuarios.
El encapsulamiento en ABox le proporciona las siguientes caracterı́sticas a

las aplicaciones:
Xelhua 87
Figura 2: Representación gráfica de los componentes de un ABox.
Agnosticidad a la infraestructura - Al encontrarse encapsuladas con todas

sus dependencias, las aplicaciones se consideran auto-contenidas, por lo que
pueden funcionar independientemente de la infraestructura en donde se en-
cuentren desplegadas;
Conectividad - Las interfaces de entrada y salida proporcionan la capacidad
de comunicarse con otros ABox ;
Manejabilidad - Los módulos de control de Xelhua proporcionan un con-
trol a la ejecución de las aplicaciones, los datos, resultados y un monitoreo
constante del estatus de la aplicación;
Portabilidad - Al ser auto-contenidos, los ABox son paquetes de software
portables, capaces de desplegarse en computadoras personales, servidores o
en la nube;
Disponibilidad - Los ABox son entidades replicables, por lo que es posible
clonarlos y desplegar múltiples copias para asegurar que siempre existan
instancias disponibles para los usuarios;
Confiabilidad - En el caso de fallas en un ABox por causas externas (e.g.
apagón de un servidor), los servicios tienen componentes de tolerancia a
fallos, por lo cual es posible redirigir peticiones de usuarios a una réplica de
un mismo ABox para no interrumpir los procesos del usuario final.
Por otro lado, Xelhua considera un enfoque orientado a microservicios. Los

microservicios son un enfoque arquitectónico para el desarrollo de software y
consiste en el desarrollo de componentes pequeños denominados servicios. Estos
servicios están separados del resto, son independientes entre sı́ y se comunican
unos con otros mediante la red. A diferencia del enfoque monolı́tico, donde el
software es un solo bloque de código, las arquitecturas de microservicio son
un conjunto de módulos separados e independientes, lo cual permite que las
aplicaciones sean más fáciles de escalar y más rápidas de desarrollar. En Xelhua
todos los componentes son microservicios, lo cual proporciona diversas ventajas
a la plataforma:
Despliegue distribuido - Al ser componentes independientes, cada uno puede

ser ubicado en diferentes contextos, ya sean en servidores públicos (ej. Ama-
zon, Azure, Digital Ocean, etc.), privados, computadores personales, etc.;
Escalabilidad de servicios de analı́tica - Los Abox que encapsulan las aplica-
ciones de analı́tica para el procesamiento de datos son independientes entre
sı́, por lo que, para desarrollar y añadir más servicios de analı́tica, no es
necesario conocer ni modificar el resto;
Grado de tolerancia a fallos - Si un servicio de analı́tica llega a fallar, el resto
de servicios no se ven afectados.
Tanto las caracterı́sticas de los ABox, como de la arquitectura de microservi-

cios, son beneficiosas a la hora de lidiar con los problemas del vendor lock-in. Por
un lado, la abstracción de los ABox permite desplegar los servicios de analı́ti-
ca en cualquier infraestructura de cómputo y conectarlos entre sı́ para generar
flujos de procesamiento sin necesidad de depender de APIs de proveedores de
nube, mientras que el desacoplamiento de los microservicios permite la distri-
bución en múltiples servidores y con diferentes caracterı́sticas, recuperando, ası́,
el control sobre los datos y aplicaciones sin necesidad de crear una dependencia
con proveedores de la nube.
3.2. El ciclo de vida de los datos
Xelhua permite manejar todas las etapas del ciclo de vida de los datos.
Adquisición: Los usuarios finales pueden subir sus fuentes de datos a la

plataforma, ya sea directamente desde su computadora (e.g. archivos csv) o
mediante el uso de conectores para la adquisición de los datos desde reposi-
torios remotos, bases de datos, etc.
Preprocesamiento: Xelhua cuenta con un conjunto de servicios previa-
mente configurados para realizar la preparación de los datos. De manera
transparente, los usuarios pueden llevar a cabo la transformación de sus
conjuntos de datos, limpiarlos de valores nulos, faltantes u outliers, norma-
lizarlos, estandarizarlos, entre otros procesos de limpieza.
Procesamiento y análisis: La plataforma cuenta con servicios de analı́tica
básica para datos estructurados, ası́ como herramientas de descubrimiento de
patrones sobre los datos y Machine Learning. Algunas de estas herramientas
son algoritmos de clustering, modelos de regresión, redes neuronales, modelos
de clasificación (KNN, Naive Bayes y Máquinas de Vectores de Soporte),
cálculos estadı́sticos, etc.
Visualización: Los resultados producidos por el resto de los servicios pue-
den ser enviados a herramientas de visualización. Mediante únicamente la
selección de parámetros, los usuarios pueden generar diversos tipos de gráfi-
cas y mapas que permitan interpretar de manera más cómoda los resultados.
Xelhua 89
Preservación: Por último, Xelhua mantiene un control sobre todas las ver-
siones de los datos y resultados generados en cada una de las etapas, por lo
cual todos los resultados son almacenados.
En Xelhua, estas etapas son representadas en forma de grafo, donde cada

nodo del grafo representa un servicio de análisis del repositorio de servicios de
Xelhua. Para la creación de este grafo los usuarios utilizan los servicios de este
repositorio; posteriormente, el grafo se materializa y se despliega en una infra-
estructura de cómputo definida. Una vez desplegados los contenedores virtuales
(los servicios), comienza la ejecución, partiendo del nodo raı́z del grafo y siguien-
do la secuencia definida por el usuario. El traslado de los datos producidos por
cada etapa es manejado por el modelo de orquestación de Xelhua y se enmasca-
ran posibles fallas en los servicios con un modelo descentralizado de réplicas y
monitoreo. Por último, los resultados se almacenan y son entregados al usuario
final. Este proceso se puede observar en la Figura 3.
Figura 3: Representación gráfica del proceso de construcción, ejecución y des-

pliegue de un sistema de ciencia de datos en Xelhua.
3.3. La interfaz del usuario

Los usuarios acceden a los servicios a través de una interfaz gráfica. La Fi-
gura 4 muestra una captura de pantalla de la versión web de Xelhua. En ésta
se puede observar un área de diseño en la parte derecha y un conjunto de cajas
en la parte izquierda. Cada una de estas cajas corresponde a una aplicación de
procesamiento o análisis de datos dentro de un contenedor virtual, el cual puede
ser utilizado a necesidad de los usuarios, dentro de un flujo de procesamiento o

de manera aislada. Los servicios están divididos en secciones, las cuales están or-
denadas de manera descendente siguiendo el ciclo de vida de los datos. Cada caja
es configurable, es decir, se adapta a los procesos que el usuario quiera realizar
mediante la modificación de parámetros. Por ejemplo, en el servicio con algorit-
mos de clustering el usuario puede modificar el valor de k (cantidad de grupos
a detectar), seleccionar las variables del dataset que se emplearán, el algoritmo
de clustering a utilizar, seleccionar si se desea validar el valor de K mediante
ı́ndices de validación, etc. El usuario final puede realizar el procesamiento de sus
datos siguiendo una serie de pasos, como los descritos a continuación, uniendo
servicios mediante movimientos drag-and-drop:
1. El usuario selecciona la fuente de datos a procesar, puede ser un archivo

directo de su computadora o que se encuentre en algún servidor en la nu-
be; hemos experimentado cargando archivos en el orden de los 100 GB de
tamaño;
2. Del catálogo de aplicaciones, el usuario debe elegir aquellos que desee usar;
por ejemplo, existen servicios para eliminar valores vacı́os, normalizar valo-
res, corregir valores, detectar outliers, realizar muestreo, generar estadı́sticos,
crear gráficas, georeferenciar datos en un mapa, etc.; los servicios se unen en
forma de grafo en el panel de la derecha, por lo cual se puede elegir el orden
en el que estas aplicaciones se van a ejecutar;
3. Para cada tarea, el usuario debe especificar los parámetros necesarios por
el algoritmo a emplear; por ejemplo, seleccionar las variables a procesar, los
rangos de valores permitidos, la función de similitud a usar, el número de
grupos a detectar, etc.;
4. Una vez realizada la configuración preliminar de las aplicaciones, el usuario
presiona el botón ejecutar para echar a andar todo el flujo de procesamiento;
5. Finalmente, una vez terminada la ejecución, el usuario puede descargar los
resultados, o bien, seguir procesándolos mediante otro flujo de trabajo, o
visualizarlos mediante gráficas o mapas dentro de la misma plataforma.
De manera transparente para el usuario, internamente ocurre una serie de

procesos que permiten que los resultados pasen de su estado original a ser pro-
cesados por las distintas aplicaciones seleccionadas. Una vez que el usuario elige
los servicios que desea ejecutar, cada una de estas aplicaciones es desplegada en
un contenedor virtual. Se crea un mapa para el traslado de los datos origina-
les a cada una de las aplicaciones seleccionadas por el usuario, en el orden que
este mismo las declaró. Los datos son recibidos por las aplicaciones, se proce-
san, entregan los resultados a la siguiente etapa y, finalmente, este contenedor se
desactiva automáticamente. Es decir, los contenedores virtuales se encienden y
apagan bajo demanda sin intervención del usuario. Si no existen peticiones por
parte del usuario, los contenedores no se activan, reduciendo, ası́, la cantidad de
procesos que se realizan en Xelhua.
Xelhua 91
Una vez que el usuario termina de diseñar su sistema de ciencia de datos, se

pueden ejecutar presionando el botón verde. Este botón enviará un conjunto de
instrucciones a una entidad coordinadora encargada del despliegue de los conte-
nedores necesarios para el procesamiento. Este proceso es transparente para el
usuario, por lo que él solo se entera de la finalización de cada uno de los procesos
mediante notificaciones y la entrega de resultados. Al finalizar el procesamiento,
el usuario puede elegir finalmente descargar los resultados de cada una de las
cajas que seleccionó, visualizar información estadı́stica de los datos procesados,
añadir más cajas, eliminar cajas o guardar y compartir el grafo a otro usuario.
Figura 4: Interfaz gráfica de Xelhua. En la parte izquierda se encuentran los

servicios arrastrables. En la parte derecha se encuentra el área de diseño de
grafos.
4. Caso de uso: Análisis exploratorio de datos de cáncer

Para mostrar la utilidad de la plataforma realizamos un análisis exploratorio
de un dataset con conteos y tasas de defunciones ajustadas por rango de edad
para distintos tipos de cáncer. El dataset cuenta valores para hombre y mujer
de los años 2000 al 2020 para todos los municipios de México. Realizar análisis
exploratorios de conjuntos de datos puede llegar a ser un trabajo laborioso, dado
que es necesario procesar y analizar múltiples resultados generados con base en
combinaciones de parámetros distintos, por ejemplo, los resultados obtenidos de
una regresión pueden variar dependiendo de las variables que se utilicen, de la
cantidad de datos, o si estos datos pertenecen a un estado en concreto, a una
ciudad, o a todo el paı́s. En este contexto, Xelhua cuenta con herramientas para
el procesamiento de datos en profundidad, de tal modo que los usuarios puedan
definir mediante parámetros la forma en que sus datos serán procesados. Para
este caso, definimos una metodologı́a de procesamiento en profundidad para cada

tipo de cáncer, estado de la República y año registrado. Como se puede ver en
la Figura 5, los usuarios finales diseñan el grafo utilizando los servicios (ABox )
disponibles. Posteriormente, se definen las variables para definir la metodologı́a
de búsqueda en profundidad. En palabras simples, el usuario define variables
presentes en el dataset, las cuales servirán para filtrarlo. En nuestro caso se
eligieron las columnas que contienen la clave con el tipo de cáncer (Causa def),
la cual fue la causa de defunción, la columna con los nombres de los estados de
la República (estado) y la columna con los valores de los años (año). En este
sentido, Xelhua realizará la división del dataset y generará un subdaset para
cada tipo de cáncer (X). Posteriormente, cada uno de estos subdatasets X se
dividirán para cada estado (Y) y, finalmente, cada uno de estos subdatasets XY
se dividirá para cada año (Z). Posteriormente, a cada subdataset generado se
le aplicará el proceso que el usuario haya definido en su grafo. De tal manera,
se generarán histogramas, gráficas, modelos de regresión linear y mapas para
las diferentes combinaciones, lo cual da un total de 89,033 productos generados
(contando los subdatasets). Cada uno de estos productos es consultable, de tal
manera que los usuarios finales pueden navegar los resultados e ir centrándose
en aquellos que más le interesen. Por ejemplo, si en el mapa de cáncer de mama
del todo el paı́s se indica un patrón de tasas elevadas en el estado de Nuevo
León, el usuario puede acceder a los productos generados para Nuevo León.
Grafo de servicios de análisis de datos diseñado por el H = Histograma C=Conglomerado

(suma de tasas ajustadas)
usuario B= Boxplot
R=Regresión linear M=Mapa georreferenciado
H B R C
M X1 X2 Xn
XnY1 X Y X Y
n 2 n m
XnYmZw
XnYmZ1
X=causa_def Y=estado Z=Año
XnYmZ2
X1 Mama
NUEVO
C1 B1 H1
Y1 LEON C2 R1
X2 Pulmon 2000 Z1
Cn
B2 R2 H2
Y2 YUCATAN
2001 Z2 M1
M2 Bn*m Rn*m Hn*m*w
Prostata MÉXICO
Xn Ym 2022 Zw Mn
Sistema de ciencia de datos materializado en una

Aplicar: C M B R H
infraestructura de computo
Metodología de procesamiento definida por el usuario
Figura 5: Representación gráfica del un sistema para el análisis exploratorio de

datos de cáncer en Xelhua.
Xelhua 93
Para un analista de datos, el generar esta gran cantidad de combinaciones y

productos puede conllevar un gran esfuerzo, además de poder perderse fácilmente
entre la gran cantidad de resultados generados. Xelhua se encarga de facilitar las
cosas mediante su despliegue orientado a diseño, proporcionándole al usuario la
interfaz gráfica para diseñar un grafo y definir la metodologı́a de procesamiento
(recuadros rojos en la Figura 5), mientras que, tras bambalinas, el despliegue de
los servicios, la orquestación de los datos y el almacenamiento de resultados es
realizado por Xelhua. En pocas palabras, Xelhua permite materializar el diseño
de un usuario en un sistema de procesamiento sobre una infraestructura de
cómputo de manera automática, además de permitir mejorar el rendimiento al
procesar las combinaciones en procesos en paralelo. Como se puede observar en
la Figura 6, al aumentar la cantidad de trabajadores (procesos en paralelo) es
posible disminuir el tiempo de procesamiento de los datos, proporcionándole una
mejor experiencia al usuario al tener que esperar menos tiempo para obtenerlos
todos. No obstante, dado que cada producto generado puede ser accedido por los
usuarios, no es necesario esperar a que todos los procesos terminen para poder
comenzar a analizar los resultados que se van produciendo.
Figura 6: Tiempo de procesamiento al aumentar la cantidad de trabajadores.

5. Conclusiones
Xelhua está pensada como una plataforma para el análisis de datos, pero
orientada al diseño de distintas formas de realizar las tareas de análisis, lo cual
permite probar distintas versiones de las tareas de análisis que son de interés
para el usuario; esta caracterı́stica es útil para la validación estadı́stica de mo-
delos en el diseño de experimentos. Xelhua tiene como caracterı́stica principal
el enfoque a la generación de estructuras complejas de procesamiento de datos
orientado al diseño, las cuales, de otro modo, serı́an agobiantes de diseñar y eje-
cutar para el usuario. Los flujos de procesamiento se forman y ejecutan siguiendo
la secuencia de nodos del grafo definido. A diferencia de otras plataformas en
la nube, Xelhua no depende de algún proveedor de servicios, por lo que es un
paquete de software que puede ser instalado y desplegado en diversas infraes-
tructuras sin llegar a depender de la infraestructura de un proveedor especı́fico.
Además, ofrece la posibilidad de escalar, tanto en la infraestructura de procesa-
miento (RAM, CPU, almacenamiento), como en el catálogo de aplicaciones para
análisis de datos. Cada aplicación en Xelhua es un contenedor virtual con una
aplicación y las librerı́as requeridas dentro. Por tal motivo, es posible añadir más
servicios a Xelhua simplemente encapsulando las nuevas aplicaciones en contene-
dores virtuales. Xelhua permite la unión, intersección y coordinación de procesos
de análisis de datos entre todos los posibles diseños de una tarea de análisis de
interés para el usuario, adaptándose a los recursos de cómputo disponibles en la
infraestructura sobre la que se esté usando. En resumen, la plataforma permite a
los desarrolladores convertir aplicaciones en servicios consumibles bajo demanda,
interconectables y altamente disponibles. Estos servicios pueden ser utilizados
por usuarios finales (sin grandes conocimientos en programación) para diseñar
sistemas de ciencia de datos, los cuales son desplegados bajo demanda de manera
automática en una infraestructura definida, manteniendo alta disponibilidad de
los servicios para el correcto procesamiento de los datos y con la capacidad de
realizar procesamiento en paralelo de manera semi-automatica para mejorar el
rendimiento.
Agradecimientos
Este trabajo fue parcialmente apoyado por el proyecto 41756 “Plataforma
tecnológica para la gestión, aseguramiento, intercambio y preservación de gran-
des volúmenes de datos en salud y construcción de un repositorio nacional de
servicios de análisis de datos de salud” por el FORDECYT-PRONACES de
Conacyt (México).
Referencias
[1] Sepideh Bazzaz Abkenar et al. “Big data analytics meets social media: A
systematic review of techniques, open issues, and future directions”. En:
Telematics and Informatics 57 (2021), pág. 101517. issn: 0736-5853. doi:
Xelhua 95
https://doi.org/10.1016/j.tele.2020.101517. url: https://www.

sciencedirect.com/science/article/pii/S0736585320301763.
[2] Wasim Ahmad Bhat y S.M.K. Quadri. Big Data promises value: Is hard-
ware technology taken onboard? 2015. url: https://www.emerald.com/
insight/content/doi/10.1108/IMDS-04-2015-0160/full/html.
[3] Juan José Camargo-Vega, Jonathan Felipe Camargo-Ortega y Luis Joyanes-
Aguilar. “Conociendo Big Data”. es. En: Revista Facultad de Ingenierı́a
24 (ene. de 2015), págs. 63 -77. issn: 0121-1129.
[4] Ismael Cuadrado-Cordero, Anne-Cécile Orgerie y Jean-Marc Menaud. “Com-
parative experimental analysis of the quality-of-service and energy-efficiency
of VMs and containers’ consolidation for cloud applications”. En: 2017 25th
International Conference on Software, Telecommunications and Computer
Networks (SoftCOM). 2017, págs. 1-6. doi: 10 . 23919 / SOFTCOM . 2017 .
8115516.
[5] Papa Senghane Diouf, Aliou Boly y Samba Ndiaye. “Variety of data in the
ETL processes in the cloud: State of the art”. En: 2018 IEEE Internatio-
nal Conference on Innovative Research and Development (ICIRD). IEEE.
2018, págs. 1-5.
[6] Reihaneh H Hariri, Erik M Fredericks y Kate M Bowers. “Uncertainty in
big data analytics: survey, opportunities, and challenges”. En: Journal of
Big Data 6.1 (2019), págs. 1-16.
[7] Yuzhe Huang et al. “SSUR: An Approach to Optimizing Virtual Machine
Allocation Strategy Based on User Requirements for Cloud Data Center”.
En: IEEE Transactions on Green Communications and Networking 5.2
(2021), págs. 670-681. doi: 10.1109/TGCN.2021.3067374.
[8] Euripidis Loukis, Marijn Janssen y Ianislav Mintchev. “Determinants of
software-as-a-service benefits and impact on firm performance”. En: Deci-
sion Support Systems 117 (2019), págs. 38-47.
[9] Markus Murhu. Containerization and deployment of a virtual learning en-
vironment. 2021. url: https://aaltodoc.aalto.fi/handle/123456789/
110549.
[10] Amit M Potdar et al. “Performance evaluation of docker container and vir-
tual machine”. En: Procedia Computer Science 171 (2020), págs. 1419-1428.
[11] Seyed Majid Razavian et al. “An analysis of vendor lock-in problem in
cloud storage”. En: ICCKE 2013. 2013, págs. 331-335. doi: 10 . 1109 /
ICCKE.2013.6682808.
[12] Youssra Riahi. “Big Data and Big Data Analytics: Concepts, Types and
Technologies”. En: International Journal of Research and Engineering 5
(nov. de 2018), págs. 524-528. doi: 10.21276/ijre.2018.5.9.5.
[13] Prateek Sharma et al. “Containers and virtual machines at scale: A com-
parative study”. En: Proceedings of the 17th international middleware con-
ference. 2016, págs. 1-13.
[14] Dilpreet Singh y Chandan K Reddy. A survey on platforms for Big Data
Analytics - Journal of Big Data. 2014. url: https://link.springer.
com/article/10.1186/s40537-014-0008-6.
[email protected], {maria.perezdecelis,
maria.somodevilla}@correo.buap.mx.


1 Cinvestav Tamaulipas, Cd. Victoria, México
{joseluis.gonzalez, diana.carrizales, dante.sanchez,
juan.barron}@cinvestav.mx
[1] Dantés, O. G., Sesma, S., Becerril, V. M., Knaul, F. M., Arreola, H., & Frenk, J.
(2011). Sistema de salud de México. Salud pública de México, 53(suppl 2), s220-s232.
-
-
Reflexiones sobre el almacenamiento digital de
las organizaciones
Ricardo Marcelı́n-Jiménez1[0000−0002−5355−5830] , José Luis

González-Compeán2[0000−0002−2160−4407] , Hugo G.
Reyes-Anastacio2[0000−0002−9003−6765] , and Dante D.
Sánchez-Gallegos2[0000−0003−0944−9341]
1
Universidad Autónoma Metropolitana (UAM), Iztapalapa, Departamento de
Ingenierı́a Eléctrica, Ciudad de México 09340, México.
[email protected]
2
Centro de Investigación y Estudios Avanzados (Cinvestav) del IPN Unidad
Tamaulipas, Cd. Victoria 87130, Tamaulipas, México.
{joseluis.gonzalez, hugo.reyes, dante.sanchez}@cinvestav.mx
Resumen A lo largo de este capı́tulo se presenta un análisis de las

diferentes tecnologı́as que pueden soportar las necesidades de almacena-
miento modernas, considerando que no existe una solución que pueda
atender todos los requerimientos asociados con el tratamiento de la in-
formación, sino que debemos pensar en la construcción de ambientes en
los que se interconectan componentes de almacenamiento que atiendan
necesidades complementarias, ası́ como los sistemas para recuperar la
información con agilidad a partir de sus metadatos o descriptores.
Palabras Clave: Big Data · Ambientes de almacenamiento · Catálogos

digitales
1. Introducción
Dejar un registro de nuestras actividades es parte de nuestra naturaleza como

seres humanos. Es establecer un diálogo con una versión futura de nosotros
mismos o con alguien que recibirá nuestro mensaje, tal vez mucho tiempo después
de que nos hayamos ido. Es guardar una nota al interior de una botella para
luego arrojarla en el vasto océano del tiempo.
La Historia, con mayúscula, comenzó cuando los registros se basaron en la
escritura. Entonces, surgió el problema de la gestión de colecciones documenta-
les y la humanidad construyó sus primeras bibliotecas. Se sabe también que en
todo tiempo el registro de la información ha estado asociado con la tecnologı́a
disponible en la época. En el siglo XXI, por ejemplo, este registro es fundamen-
talmente de naturaleza digital, esto es, electrónica de signos binarios. En la Fig.
1 se muestran diferentes ejemplos de mecanismos de almacenamiento actuales.
Por su parte, la gestión de las colecciones implica la catalogación y preser-
vación de los documentos. Estas dos funciones van de la mano pero, en nuestro
140 Marcelı́n-Jiménez R. et al.
Figura 1: Ejemplos de mecanismos de almacenamiento de datos actuales.
tiempo, el volumen implica nuevos retos. En el 2020, por ejemplo, se generaban,

cada minuto del año, 500 horas de video en YouTube, 347,222 publicaciones
en Instagram, 28 canciones en Spotify [3]. Se sabe también que el 75 % de la
información es producida por individuos, pero el 80 % de la misma está bajo
la responsabilidad de organizaciones. Se prevé un crecimiento exponencial en el
tamaño del “universo digital”, pasando de 33 Zettabytes (ZB) en 2018 a 175 ZB
en 20253 [8].
Este capı́tulo es un trabajo basado en la experiencia de los autores. No es
un reporte de investigación, sino un artı́culo de opinión que invita a la reflexión
sobre las tendencias en las tecnologı́as de almacenamiento. Dado que el mayor
porcentaje de las operaciones relacionadas con la preservación de contenidos di-
gitales está asociada con las organizaciones, en la sección 2 se revisan los procesos
de las mismas que dan lugar a los flujos de información. A partir de ello, se des-
criben ejemplos en los que se utilizan diferentes tipos de almacenamiento a lo
largo de la vida útil de los documentos. Lo anterior da pie para que, en la sección
3, se presenten los llamados paradigmas de almacenamiento y se describa cómo
obedecen a diferentes necesidades. A continuación, en la sección 4, se presenta
un caso de estudio que recupera las ideas expuestas previamente. Por último, en
la sección 5 se realiza una serie de consideraciones acerca de las decisiones que
deben tomar las organizaciones para abordar el problema del almacenamiento
de largo plazo y cerramos reflexionando sobre las limitaciones de las soluciones
consideradas, en término de su disponibilidad en el muy largo plazo.
3
Para mayor referencia, un ZB son mil millones de Terabytes (TB).
Reflexiones sobre el almacenamiento digital de las organizaciones 141
2. Los procesos de las organizaciones
En vista de que son las organizaciones las que custodian los mayores volúme-
nes de documentos digitales, deberı́amos entender los ciclos de vida que experi-
menta la información que tienen bajo su resguardo, si queremos abordar los retos
de la gestión de volúmenes masivos de información. A lo largo de su ciclo de vida,
el cual está determinado por los objetivos de la organización y sus compromisos,
la información puede moverse entre distintas colecciones que pueden alojarse
entre distintos repositorios. Se sabe, como en el caso de la imagenologı́a médica,
que los documentos pasan por diferentes épocas o momentos, que reflejan un
estatus [6], [7], por ejemplo, para reducir el tamaño requerido por su almace-
namiento y para brindar caracterı́sticas de seguridad como confidencialidad y
control de acceso (ver ejemplo en la Fig. 2). Al inicio de su vida se les consulta
con mayor frecuencia y en algún momento pueden desecharse o preservarse, si
se prevé alguna consulta de carácter histórico.
Compresión Cifrado
Almacenamiento
en la Nube
Simbología
Documento Documento Documento

Interfaz de comunicación
Original Comprimido Cifrado
Figura 2: Ejemplo del ciclo de vida de documentos médicos con etapas de com-
presión y cifrado.
Bajo esta perspectiva, algunos sistemas ya consideran la existencia de dife-

rentes tipos de almacenamiento por los que pueden pasar los documentos digi-
tales de la organización. Al realizar un diseño moderno se debe contemplar un
almacenamiento primario, en el que se guardan los documentos que son consul-
tados en el dı́a a dı́a. Por tanto, este almacenamiento debe ser de baja latencia,
esto es con bajos tiempos de respuesta, aunque no se espera que sirva para alo-
jar un volumen masivo. Además, debe de existir un almacenamiento secundario
en el que se aloja la colección histórica y que, de ser necesario, pueda soportar
el movimiento de documentos desde o hacia el almacenamiento primario. En la
Fig. 3 se muestra un ejemplo de los tipos de almacenamiento que pueden estar
presentes en una organización. Se espera, en cambio, que el almacenamiento se-
cundario pueda acomodar una cantidad masiva de documentos por periodos de
tiempo más largos, a costa de una mayor latencia.
Disco duro
Disco de Estado
Solido Servidor Almacenamiento
Usuario NAS en la Nube
Simbología
Almacenamiento Primario Almacenamiento Secundario
Interfaz de comunicación
Figura 3: Ejemplo de los tipos de almacenamiento en una organización.
3. Los paradigmas de almacenamiento

Las necesidades para las que se han pensado los diferentes tipos de alma-
cenamiento digital nos obligan a revisar los llamados paradigmas tecnológicos.
Se dice que los dispositivos de almacenamiento obedecen a uno de los siguientes
paradigmas: por archivos, bloques u objetos. Para entender las diferencias entre
estos podemos recurrir a la relación que guardan entre sı́ los documentos alma-
cenados y los descriptores de dicha colección, a los que podemos denominar sus
metadatos.
Figura 4: Explorador de archivos en Ubuntu.
En el almacenamiento por archivos tenemos una colección de documentos

relativamente pequeña (hasta algunos TB) que vive en el mismo dispositivo que
sus metadatos. Por su parte, estos contemplan tanto los detalles de su uso, como
los detalles de su alojamiento. Con ello, queremos decir que los metadatos se or-
ganizan en un modelo lógico denominado sistema de archivos con una estructura
jerárquica o arborescente, en la que se definen carpetas y archivos y se describen
los derechos de acceso de aquellos usuarios que pueden trabajar con ellos. Por
ejemplo, en la Fig. 4 se muestra el explorador de archivos de Ubuntu, el cual está
basado en un sistema de almacenamiento por archivos. Además, también se in-
cluyen los detalles fı́sicos como (en el caso de los discos mecánicos) los cilindros,
sectores y pistas que contienen a los documentos digitales de la colección.
Por su parte, en el almacenamiento por bloques, los documentos y sus meta-
datos se alojan en dispositivos distintos, con la diferencia de que los documentos
se fragmentan y, posiblemente, se reparten entre varios dispositivos para aumen-
tar la posibilidad de acceder a ellos de manera concurrente y, con ello, ganar
en velocidad de escritura/lectura. Tanto los dispositivos de almacenamiento por
archivos como los de bloques se conocen como dispositivos transaccionales. Ello
quiere decir que los documentos que se almacenan pueden recuperarse con faci-
lidad para modificarse a lo largo del tiempo.
Finalmente, el almacenamiento por objetos está pensado para acomodar
volúmenes de información en la escala de los Petabytes (PB) o más, incluso.
La colección de documentos y sus metadatos se almacenan en dispositivos di-
ferentes. Cada documento de la colección pasa por algunas etapas de procesa-
miento antes de ser almacenado. Entre otras cosas, se le puede fragmentar y
luego se genera algún tipo de codificación de redundancia que da lugar a una o
varias secuencias de dı́gitos binarios llamadas objetos. Cada objeto se emplaza
dentro de un espacio lógico de almacenamiento que, a diferencia de los modelos
jerárquicos, puede entenderse como un espacio plano. Sobre este espacio lógico
se mapean las capacidades de los dispositivos fı́sicos que constituyen al sistema.
Hay que considerar que, en vista de su escala, la capacidad de almacenamiento
se consigue con la participación de un número de dispositivos fı́sicos que crece
en la medida en que aumenta la capacidad del sistema en su conjunto.
Un sistema de almacenamiento por objetos debe construirse como un sistema
distribuido, definido por software, que soporte una interfaz estándar y optimice
el manejo de la redundancia. Las organizaciones deben diseñar sus soluciones
de almacenamiento pensando en la disponibilidad en el corto, mediano y lar-
go plazo, lo cual implica una cuidadosa combinación de paradigmas. Esta idea
de incorporar diferentes tipos de almacenamiento es a lo que en este trabajo
llamamos “un ambiente de almacenamiento”.
Por lo que toca a los sistemas de almacenamiento definidos por software,
se trata de sistemas que utilizan mecanismos de software para proporcionar
dispositivos virtuales, sobre los que pueden efectuarse las operaciones de alma-
cenamiento y recuperación de información, con independencia de la tecnologı́a
que los sustenta. La principal ventaja de este tipo de soluciones es que otorga
a los administradores la libertad para elegir o cambiar proveedores, sin perder
continuidad en los servicios que se ofrecen o caer en dependencias tecnológicas.
4. El caso del fondo documental de la UAM
Figura 5: Diagrama del Sistema de Gestión Documental “Fondo UAM”.
Presentamos a continuación una descripción del Sistema de Gestión Do-

cumental “Fondo UAM”. Se trata de un sistema construido para la Rectorı́a
General de la Universidad Autónoma Metropolitana, que contempla la gestión
documental de colecciones catalogadas, ası́ como su preservación de largo pla-
zo. La solución integra una plataforma de software denominada DSpace, que
ha sido conectada con un sistema de almacenamiento por objetos denominado
Aleph, que es un desarrollo a la medida, el cual ofrece un espacio escalable y
de alta disponibilidad (véase la Fig. 5). Para la creación de un repositorio do-
cumental se requiere de una plataforma de software capaz de ofrecer una serie
de atributos para el manejo de una colección digital catalogada, entre los que
podemos mencionar: soporte de normas internacionales para la descripción de
los recursos (Dublin Core, o DICOM, por ejemplo), capacidad para interoperar
con otros repositorios, definición de roles para la gestión de la colección, defini-
ción de atributos de acceso para cada uno de los recursos catalogados (públicos,
privados, de grupo), capacidad para crecer el volumen de la colección (escala-
bilidad), garantı́as de disponibilidad e integridad de la información. Existe un
interés mundial por el uso de este tipo de plataformas, lo que ha dado origen a
un conjunto de soluciones, entre las que podemos citar casos tales como: DSpace,
OpenRepository, Archimed, Fedora, Eprints, entre otros [9], [2], [1], [5], [4].
De todos los repositorios institucionales en funciones, a nivel mundial, el 48 %

de ellos utiliza DSpace como su plataforma de base. Se trata de un software de
código abierto que provee herramientas para la administración de colecciones
digitales. Soporta una gran variedad de documentos, incluyendo libros, tesis, re-
vistas, fotografı́as, pelı́culas, datos de investigación y otras formas de contenido.
Un repositorio institucional soportado por DSpace se estructura por comunida-
des y colecciones. Cada comunidad contiene subcomunidades y/o colecciones y,
finalmente, las colecciones contienen elementos (ı́tems). Por su parte, un elemen-
to puede contener uno o varios archivos digitales. Los usuarios se organizan en
cuentas personales y de grupo. Cada usuario tiene definida una serie de permi-
sos y autorizaciones que abarcan desde el acceso restringido en lectura, hasta
el acceso sin restricciones para escritura, lectura, modificación y eliminación de
registros. Entre algunas de las ventajas de DSpace se encuentra el hecho de que
es totalmente configurable y personalizable, lo que permite adaptarlo a las ne-
cesidades de las instituciones que lo adoptan. El conjunto de organizaciones que
ya han adoptado DSpace incluye desde pequeños equipos o empresas (públicas
o privadas) hasta los gobiernos federales de varios paı́ses.
Como hemos argumentado a lo largo de las secciones previas, un sistema de
gestión documental requiere de dos tipos de almacenamiento: el primario o de
corto plazo, que tiene una capacidad limitada e igualmente una baja latencia
de acceso y, por otro lado, un almacenamiento secundario o de largo plazo, que
tiene una capacidad que puede crecer, incluso, a escalas de petabytes (PB). Por
su diseño, DSpace fue pensado solamente para contar con un almacenamiento
primario que reside en la computadora donde se instala el servicio de catalo-
gación. En este sentido, nuestra oferta de valor consiste en el desarrollo de una
interfaz que conecta a DSpace con un almacenamiento secundario que se describe
a continuación.
El sistema de almacenamiento Aleph es un sistema definido por software que
ofrece garantı́as de escalabilidad y alta disponibilidad, ası́ como un manejo efi-
ciente de la información redundante. Entre sus caracterı́sticas más relevantes
podemos mencionar un cuidadoso desacoplamiento entre su colección documen-
tal y sus metadatos, un middleware que garantiza la consistencia de los meta-
datos que se manejan como una base de datos replicada, ası́ como sus propios
procedimientos para balanceo de carga y almacenamiento de objetos, los cuales
se adaptan al número y capacidades de los dispositivos de almacenamiento que
componen el sistema.
Para el diseño del Fondo UAM propusimos que cada documento que se recibe
en el almacenamiento primario del servidor de DSpace se respalde en automático
en Aleph. De igual manera, todos los metadatos de las colecciones se respaldan
regularmente en el propio Aleph para habilitar procedimientos de recuperación
en caso de desastres. Para optimizar el uso del almacenamiento primario, propu-
simos un mecanismo de tiempo que elimina todos los documentos que no se han
consultado al cabo de un plazo que puede programarse. Si luego de una consulta
se requiere un documento que ya no se encuentra en el primario, entonces se
recupera del Aleph y se vuelve a emplazar en el primario, de manera transpa-
rente para el usuario final. Llamamos a esta nueva organización “el modelo de
biblioteca cerrada”, porque, como ocurre en algunas bibliotecas, los usuarios no
están autorizados para interactuar con todas las colecciones. En su lugar, existe
un bibliotecario que almacena y recupera cualquier documento que se almacena
en la gran estanterı́a. Hemos construido un bibliotecario automático que es el
único autorizado para interactuar con los documentos guardados en el Aleph.
Consideramos que este modelo propuesto ofrece algunas ventajas para el ma-
nejo de las colecciones: 1) soporta un servicio ágil para un número importante de
usuarios concurrentes con diferentes necesidades; 2) es posible manejar diferentes
tipos de colecciones y catálogos usando el mismo servidor; 3) la comunicación
entre el almacenamiento primario y secundario permite que el primero no se sa-
ture sin que se limite el tamaño de las colecciones que son ingresadas al sistema;
y 4) al mismo tiempo, el almacenamiento secundario ofrece un almacenamiento
de largo plazo.
5. Reflexiones finales
Estamos atestiguando la evolución de las tecnologı́as de almacenamiento.
Entre los implicados inmediatos en esta transformación podemos mencionar al
gobierno, los servicios financieros, el sector salud y todas las organizaciones cu-
yos procesos de negocio están fuertemente vinculados con las tecnologı́as de la
información y comunicaciones (TIC). En los próximos años, los administrado-
res de las TIC (CTO: Chief Technology Officers) deberán tomar importantes
decisiones concernientes a las capacidades de almacenamiento de sus organiza-
ciones: ya sea que estas capacidades se soporten basándose en recursos propios,
como un servicio provisto por un tercero, o una combinación de diferentes solu-
ciones dentro y fuera de casa, es decir, su infraestructura propia y de terceros.
Sin embargo, los cambios impulsados por esta transformación llegarán hasta las
pequeñas organizaciones y, aun, a los usuarios particulares.
Por otra parte, estamos observando la construcción de grandes sistemas pa-
ra el almacenamiento masivo de datos. Sin embargo, puestos en perspectiva,
tendrı́amos que preguntarnos si la información que en ellos hemos deposita-
do podrı́a sobrevivir la prueba del tiempo. La mayor dificultad que podemos
reconocer es que se trata de sistemas electrónicos que requieren de energı́a pa-
ra mantenerse en operación. Si queremos garantizar un registro de largo plazo
tendrı́amos que pensar en soluciones que no requieran de energı́a, o bien, que
sean capaces de proveerse a sı́ mismos de esta. Las mejores soluciones son aque-
llas que se volvieron invisibles y “siempre” han estado ahı́. Dicho de otro modo,
¿de qué manera se guarda información en la naturaleza? Al inicio de esta refle-
xión mencionamos que no existe una solución de almacenamiento que acomode
todas las necesidades asociadas al ciclo de vida de la información. Tal vez, en
algún momento, los ambientes de almacenamiento deberán incorporar compo-
nentes biológicos para la preservación de muy largo plazo, si es que queremos
apostar a que el mensaje en la botella nos sobreviva. Reconocemos, sin embargo,
que esta última reflexión entra en el terreno de lo especulativo.
6. Agradecimientos
Este trabajo ha sido parcialmente apoyado por el proyecto No. 41756 ti-
tulado “Plataforma tecnológica para la gestión, aseguramiento, intercambio y
preservación de grandes volúmenes de datos en salud y construcción de un repo-
sitorio nacional de servicios de análisis de datos de salud” del fondo PRONACES-
CONACYT.
Bibliografı́a
[1] Archimed. Archimed - Gestion de la connaissance. Available at: https :
//www.archimed.fr/, Last accessed: 2022-10-27. Oct. de 2022.
[2] Inc Atmire. Open Repository - premium DSpace hosting. Available at: http
s://www.openrepository.com/, Last accessed: 2022-10-27. Oct. de 2022.
[3] DOMO. Data never sleeps. https://www.domo.com/learn/infographic/
data-never-sleeps-8. 2019.
[4] University of Southampton Electronics & Computer Science. EPrints Ser-
vices. Available at: https://www.eprints.org/uk/, Last accessed: 2022-
10-27. Oct. de 2022.
[5] Lyrasis Fedora. Fedora is the flexible, modular, open source repository plat-
form with native linked data support. Available at: https://duraspace.
org/fedora/, Last accessed: 2022-10-27. Oct. de 2022.
[6] Josefina Gutiérrez-Martı́nez et al. “A software and hardware architecture
for a high-availability PACS”. En: Journal of digital imaging 25.4 (2012),
págs. 471-479.
[7] O.S Pianykh. Digital imaging and communications in medicine (DICOM)
Cap 11. DICOM Media and Security. Springer 2nd Edition, 2012.
[8] David Rydning et al. “The digitization of the world from edge to core”. En:
Framingham: International Data Corporation 16 (2018).
[9] Chris Wilper. DSpace 4. x Documentation. https://wiki.lyrasis.org/
display/DSDOC4x. 2016.
{victor.morales, alan.ponce}@uacj.mx, [email protected]
─
─
─
1 La terminología SNOMED CT se puede consultar en https://browser.ihtsdotools.org/?

2 Para más información de Hyperledger Besu se puede consultar https://www.hyperled-
ger.org/use/besu
Muyal-Painal: Servicio para el transporte y
almacenamiento de datos médicos
José Luis González-Compeán1[0000−0002−2160−4407] , Victor J.

Sosa-Sosa1[0000−0001−5465−0410] , and Hugo G.
Reyes-Anastacio1[0000−0002−9003−6765]
Centro de Investigación y Estudios Avanzados (Cinvestav) del IPN Unidad

Tamaulipas, Cd. Victoria 87130, Tamaulipas, México.
{joseluis.gonzalez, vjsosa, hugo.reyes}@cinvestav.mx
Resumen Muyal-Painal es un conjunto de servicios y sistemas desarro-

llados para que las organizaciones de salud y la comunidad cientı́fica
puedan: i) almacenar, distribuir y localizar sistemas o servicios de proce-
samiento a través de catálogos de servicios; ii) generar soluciones que per-
mitan brindar rentabilidad costo-beneficio del almacenamiento y trans-
porte de datos; iii) almacenar, publicar y transmitir repositorios de datos
de manera local (intra-institucional) y federada (inter-institucional) uti-
lizando un modelo de publicación/suscripción interconectando la infraes-
tructura de TI privada con servicios de nube (pública o hı́brida). Painal
permite crear catálogos de servicios para que las organizaciones coloquen
sus sistemas, servicios o aplicaciones para que otras instituciones de la
federación puedan descargarlos y utilizarlos. También, es posible crear
catálogos de datos para el almacenamiento persistente y compartición se-
gura de los mismos entre múltiples organizaciones mediante técnicas de
compresión, seguridad y paralelismo que permiten reducir el espacio de
almacenamiento requerido, brindar control de acceso y confidencialidad
a los datos, ası́ como reducir el tiempo de respuesta de las soluciones.
Palabras Clave: Big Data · Catálogos · Almacenamiento Federado ·
Almacenamiento Seguro
1. Introducción
El volumen de datos producidos y gestionados por las organizaciones ha ido

creciendo en los últimos años; esto, debido a que los usuarios, de manera in-
dividual o asociados a una organización, producen, almacenan y utilizan datos
de manera constante y continua, por ejemplo crean o recolectan nuevos datos
(fotos, documentos, audio, vı́deo, etc.), ocasionando un efecto de acumulación
de datos [19]. Los usuarios y las aplicaciones contratan los servicios de almace-
namiento en la nube para solucionar su problema de almacenamiento a través de
un modelo de negocio denominado pago por uso (pay-as-you-go) [8]. A pesar de
que estos servicios se construyen utilizando sistemas distribuidos, una acumula-
ción constante de datos crea, de manera gradual, una colección centralizada de
162 González-Compeán J. L. et al.
datos en dichos servicios de almacenamiento. Esto no solo da lugar a un único

punto de fallo en los escenarios de interrupción [13], es decir, si el proveedor
deja de responder las peticiones de los usuarios, éstos no tendrán acceso a los
datos. Adicionalmente, se produce una dependencia con el proveedor de estos
servicios [23], haciendo que el usuario dependa de sus herramientas y dificultan-
do la migración de sus datos a otro servicio. A esta dependencia se le denomina
vendor lock-in [24]. La gestión del almacenamiento de datos resulta un proceso
clave para que los usuarios y organizaciones reduzcan la saturación y centraliza-
ción de sus datos en un solo proveedor de almacenamiento en la nube, ası́ como
para reducir el tiempo de respuesta de los intercambios de datos en lı́nea con
sus socios (inter-institucionales) y otros usuarios (intra-institucionales). En un
escenario de intercambio de datos, los aspectos de rendimiento y gestión del al-
macenamiento resultan crı́ticos, sobre todo en enfoques jerárquicos con distintos
niveles de acceso utilizando infraestructuras heterogéneas, es decir, de entornos
donde los recursos tienen caracterı́sticas diferentes [1], [26].
En este documento se presenta el servicio Muyal-Painal o Painal, el cual
se compone por un conjunto de servicios que permiten realizar el transporte,
almacenamiento y gestión de datos médicos a través de catálogos digitales que
son accedidos mediante un modelo de publicación/suscripción (Pub/Sub). Painal
permite realizar la compartición segura de servicios y datos entre diferentes
instituciones con el objetivo de mejorar los procesos de intercambio de datos
sensibles a través de un entorno regulado (federado).
Painal puede ser utilizado por personal de la salud para compartir datos de
un paciente a través de las diferentes etapas del ciclo de vida de los mismos.
Por ejemplo, si a un paciente le realizan una tomografı́a, las imágenes y textos
asociados con la misma pueden ser colocados en un repositorio digital, al que lla-
mamos catálogo, el cual es una carpeta que posiblemente se ubica en un servidor
del hospital donde se guardan la información relacionada con el paciente en cues-
tión. Este catálogo podrá ser compartido, de manera transparente, a través del
servicio que proporciona Painal. Una vez compartido el catálogo, un médico con
acceso al mismo podrá visualizar la tomografı́a, de manera casi inmediata, desde
su computadora, gracias a que cuenta con Painal. En caso de ser necesario, el
catálogo también podrá ser compartido con un especialista, posiblemente de otro
hospital, que cuente también con el servicio de Painal. En este escenario, solo el
paciente y los médicos que dan seguimiento a su caso tienen acceso a los datos,
aún cuando existan otros médicos, técnicos y especialistas que pudieran estar
accediendo a Painal. Lo anterior, gracias a que Painal cuenta con un servicio de
control de acceso y asignación de permisos que se hace responsable de verificar
que los usuarios solo accedan a los datos que les corresponden, proporcionando,
ası́, confidencialidad a los mismos.
1.1. Definiciones
En esta sección se proporcionan algunas definiciones que permitirán al lector

comprender los principales componentes y servicios que proporciona Painal.
Muyal-Painal: Servicio de transporte y almacenamiento de datos médicos 163
Cómputo en la nube (Cloud computing): El Instituto Nacional de Estánda-

res y Tecnologı́a (NIST, por sus siglas en inglés) define el cómputo en la
nube como “un modelo que permite el acceso ubicuo, conveniente y bajo de-
manda a un conjunto de recursos computacionales configurables que pueden
ser rápidamente provistos y lanzados con el mı́nimo esfuerzo de manejo o
interacción con el proveedor de servicio” [21]. Dicho modelo cuenta con cinco
caracterı́sticas esenciales: autoservicio bajo demanda, amplio acceso a la red,
conjunto de recursos heterogéneos, rápida elasticidad y un servicio medido.
Los modelos de servicio a los que se tiene acceso a través del cómputo en la
nube son Software como Servicio (SaaS, del inglés Software as a Service) e
Infraestructura como Servicio (IaaS, del inglés Infraestructure as a Service),
los cuales se despliegan en cuatro modelos de nube diferentes: pública, comu-
nitaria, privada e hı́brida [14]. La nube pública es la que se encuentra fuera
de las instalaciones de la organización y es completamente manejada por el
proveedor de servicios, en donde el usuario final solo accede a los recursos a
través de internet. La nube comunitaria es aquella donde un grupo de organi-
zaciones se integran para compartir los recursos, los cuales pueden gestionar
en un ambiente tipo federado. En el caso de la nube privada, la organización
cuenta con las instalaciones y equipo necesario para desplegar un entorno
de nube en donde tienen completo control sobre los recursos y de cómo se
manejan los procesos. Por último, la nube hı́brida es una combinación entre
la privada y la pública, en donde se establecen y gestionan qué operaciones
se hacen en la organización y cuáles son delegadas a un proveedor.
Arquitectura de malla: Es la manera en la que se le conoce a un conjun-
to de nodos de almacenamiento que trabajarán en conjunto para guardar
información de manera segura y confiable. Los nodos de almacenamiento
se interconectan creando una red (a la que se le conoce como red P2P sin
servidor). La idea básica es ofrecer a las organizaciones la posibilidad de
construir soluciones de almacenamiento basadas en sus recursos disponibles,
locales o remotos; estos últimos pudieran, por ejemplo, estar alojados en la
nube. Además, las organizaciones pueden elegir los parámetros a alto ni-
vel (es decir, el número de nodos de almacenamiento necesarios para una
solución determinada) y, de esta manera, Painal generará un servicio de al-
macenamiento confiable sin servidor, conocido también como SeRSS, por sus
siglas en inglés.
Infraestructura heterogénea: Se refiere a un conjunto de recursos de cómputo
utilizados para desplegar los clientes de los servicios, que tienen caracterı́sti-
cas de hardware (capacidad de almacenamiento, memoria o procesador), soft-
ware (sistema operativo) o infraestructura (nube pública, privada o hı́brida)
diferentes.
Mecanismo de publicación/suscripción: En Painal, representa un mecanismo
utilizado para la publicación/compartición de datos a través de catálogos de
documentos o servicios, el cual es responsable de preparar los datos previos a
ser mandados a través de la red, y que serán consumidos por otro servicio de
suscripción/adquisición de datos, el cual reconstruye los datos para que sean
visibles para el usuario final. Es complementado con técnicas de seguridad,

integridad y control de acceso para que los datos sean veraces y que solo los
usuarios con los permisos correspondientes puedan acceder.
Metadato: En Painal se le denomina metadato a las caracterı́sticas que des-
criben a los datos, archivos o contenido digital que es compartido a través de
él, por ejemplo, el nombre del archivo, el tamaño original, la ruta del servidor
donde se encuentra almacenado, ası́ como de los archivos que contienen las
credenciales de control de acceso requeridas para extraer el contenido de los
archivos.
Multi-hilo: En Painal, las aplicaciones ejecutadas en multi-hilo son genera-
das mediante paralelismo basado en tareas, el cual clona una aplicación y
los clones son ejecutados en cores o hilos de procesamiento independientes
administrados por Painal. Este proceso es transparente para el usuario final,
ya que el proceso cliente se encarga de analizar el equipo en el que es desple-
gado y utiliza los recursos disponibles con el objetivo de reducir el tiempo
de respuesta de la aplicación, es decir, proporcionar al usuario un mejor des-
empeño al momento de intercambiar datos entre los equipos que comparten
catálogos mediante Painal.
Requerimiento no funcional: Se le conoce como requerimiento no funcional
a la parte del sistema que describe el cómo un software debe de realizar una
tarea, por ejemplo, los requisitos de rendimiento del software, los requisitos
de la interfaz externa del software, las restricciones de diseño del software
y los atributos de calidad del software. Los requisitos no funcionales son
difı́ciles de probar, por lo tanto, generalmente se evalúan de forma subjetiva
[6].
Patrón peer-to-peer (P2P): En Painal, cuando un nodo puede representar
las funciones tanto de Cliente como de Servidor, se le conoce como peer. En
el patrón P2P, los nodos pueden tanto guardar información que otros nodos
le envı́an, como solicitar información de otros nodos. De esta manera, la
información no se encuentra concentrada en un solo punto. Debido a esto, si
falla un peer, es posible seguir utilizando el patrón de forma normal. Además,
la información no se solicita directamente a un mismo peer, sino que se
encuentra distribuida, por lo que los peers no se saturarán de peticiones.
Tablas hash distribuidas (DHT, por sus siglas en inglés): Son estructuras que
permiten el acceso a datos en un ambiente distribuido de manera eficiente.
Representan el ı́ndice de un sistema de almacenamiento de datos confiable,
escalable y de área amplia, que permite a los programadores reducir las com-
plicaciones de construir un sistema distribuido. Las DHT almacenan bloques
de datos en cientos o miles de computadoras conectadas a internet, replican
dichos datos para mayor confiabilidad y permiten ubicarlos rápidamente a
pesar de ejecutar enlaces de área amplia y alta latencia. Las DHT abordan
los problemas de localización de datos y fiabilidad, que son comunes en mu-
chos sistemas distribuidos, sin trabajo adicional por parte de la aplicación.
Las DHT proporcionan una interfaz genérica, lo que facilita que una amplia
variedad de aplicaciones adopten las DHT para almacenamiento [7].
Modelo RESTFul: Refiere a un modelo de interacción entre sistemas de ma-
nera abierta y escalable, utilizando Interfaces de Programación de Aplica-
ciones (API, por sus siglas en inglés) que se ajusta a los lı́mites de una
arquitectura de ambientes distribuidos conocida como REST [10].
2. Servicio de publicación/suscripción (pub/sub) para el

manejo de catálogos, fuentes y repositorios
El servicio de Painal permite crear catálogos de datos para el almacena-

miento y compartición de datos (intra e inter-institucional) de manera segura
y transparente para el usuario.1 Dentro de los catálogos de datos se pueden al-
macenar datos en crudo (sin procesar, por ejemplo, una tomografı́a que no está
convertida a imagen) o los resultados obtenidos por algún tipo procesamiento
(por ejemplo, imágenes procesadas por un algoritmo de inteligencia artificial que
permite etiquetar posibles casos de cáncer para asistir al especialista). Cuenta
con un mecanismo de publicación/suscripción que permite generar catálogos de
datos, agregar nuevos datos a dichos catálogos, transmitirlos a través de la red y
descargarlos en otro equipo de manera segura. Todo el proceso de publicación y
suscripción se basa en la utilización de tokens de acceso que permiten verificar la
identidad de las organizaciones de la federación y los permisos que tienen para
acceder a los catálogos.
Painal cuenta con un sistema de distribución de contenidos federado (FedCDS,
por sus siglas en inglés) empleado para crear servicios de sincronización de datos
médicos que permite a las organizaciones desplegar sus servicios en una nube pri-
vada, pública o hı́brida que se comunica con el gestor de Painal para el manejo de
metadata y acceso a los servicios de publicación y suscripción. La Fig. 1 muestra
una representación conceptual del FedCDS que permite compartir datos (p. ej.,
tomografı́as, mamografı́as y resonancias magnéticas) de forma sincrónica entre
tres hospitales (puede ser cualquier tipo de organización) a través de una red de
entrega de contenidos (CDN, por sus siglas en inglés) [15], [11]. La motivación
para el uso de una red de servicios federada es que las organizaciones puedan
tener un gobierno sobre sus servicios, datos, infraestructura y los requisitos no
funcionales (NFR) mediante la inclusión de métodos para cumplirlos. Además,
los miembros de la federación pueden generar un conjunto de servicios que per-
mita a los participantes compartir recursos y datos con otras instituciones. Los
servicios incluyen la preparación y recuperación de datos [12]. Estos servicios son
descritos en Muyal-Chimalli, el cual es también conocido como Zamna [2]. Su
tarea es preprocesar los datos antes de distribuirlos a otros participantes de la
1
Con transparente nos referimos a que el usuario no ve los procesos que son utilizados
para agregar estas caracterı́sticas ni interactúa de forma directa con ellos, pero estos
siempre se ejecutan
federación o a la nube, aplicando diferentes filtros que cumplan con los requisi-
tos no funcionales requeridos por una organización. Al combinar los catálogos de
servicios con la compartición de recursos y datos se obtiene una alta fiabilidad,
distribución de la carga, integridad de los datos, confidencialidad de los datos y
la independencia del proveedor de servicios de nube.
Figura 1: Ejemplo de un sistema de distribución de contenidos federado para tres

organizaciones [3].
2.1. Sistema para la distribución de contenidos y administración de

requerimientos no funcionales para una organización
El servicio de pub/sub para una organización de Painal divide la entrega
de contenidos en dos capas: Patrón de Pub/Sub y dispersión de información.
La primera capa permite devolver el control de los metadatos al propietario del
contenido. Esta capa establece los siguientes roles:
Editores - Son los usuarios responsables de producir nuevos datos o contenido
digital;
Usuarios finales - Clientes externos o consumidores que se suscriben a los
contenidos con el objetivo de descargarlos en su equipo;
Editores/administradores - Son los usuarios de la organización responsables
de aceptar/rechazar tanto las publicaciones como las suscripciones.
La segunda capa se basa en el esquema de dispersión de información descrito
en [20], el cual actúa sobre una plataforma de almacenamiento multi-nube con
la que el servicio de pub/sub consigue un uso eficiente del espacio de almacena-
miento (se reduce la cantidad de datos almacenados) y una alta fiabilidad (los
datos pueden ser descargados aun cuando uno o varios nodos de almacenamiento
se encuentren fuera de lı́nea). La Fig. 2 (izquierda) presenta el flujo de trabajo
de publicación: (1) se lee el contenido a transmitir; (2) la aplicación del Edi-
tor (o productor de contenido) procesa el contenido utilizando un algoritmo de
dispersión; y (3) el Editor transmite un conjunto de archivos llamados disper-

sos (que son redundantes y anónimos, utilizando procesos descritos en Zamná
[2]) a diferentes proveedores de nube (p. ej. Google Drive, One Drive, Amazon
S3, etc.). De esta manera, se garantiza que un determinado proveedor no reci-
be suficientes dispersos para reconstruir el contenido original, garantizando la
confidencialidad.
(3) (A)
(2) (B)
(C)
(1)
Aplicación Aplicación
Editor Usuario
final
Flujo de trabajo de publicación Flujo de trabajo de recuperación
Figura 2: Flujos de trabajo requeridos por los procesos de publicación y recupe-

ración de datos mediante Muyal-Painal.
Por otro lado, la Fig. 2 (derecha) presenta el flujo de trabajo de recupera-

ción: (A) la aplicación Usuario final (o consumidor de contenido) recupera un
subconjunto de bloques del contenido que se desea recuperar; (B) ejecuta la apli-
cación que reconstruyen el contenido; y (C) almacena el contenido en la carpeta
del usuario final. Debido a la técnica de redundancia aplicada, la recuperación
puede obtener contenidos incluso cuando algunas ubicaciones de almacenamien-
to en la nube no estén disponibles. Como resultado, se reducen los riesgos de la
dependencia del proveedor y permite a la organización externalizar el almace-
namiento de contenidos de forma controlada a proveedores de servicios de nube
públicos.
La Fig. 3 muestra las capas de manejo de metadatos (a través del gestor de
Painal 2 ) y la capa de pub/sub, ejemplificando la entrega de contenidos median-
te un esquema de colaboración. Para este ejemplo, un editor envı́a una publi-
cación de contenido (|𝐶|) a la capa de flujo de metadatos (𝑃 𝑢𝑏). Cuando un
editor/administrador de la organización autoriza la publicación de este conteni-
do, el editor se encarga de dispersarlo a múltiples ubicaciones de almacenamiento
en la nube, mediante un flujo de trabajo de entrega (etiqueta 𝐷𝑦) que se ejecuta
2
El gestor de Painal es el componente encargado de controlar los flujos pub/sub en
la capa de metadatos y de coordinar el almacenamiento de contenidos en la capa de
flujo de contenidos.
en la computadora personal del editor (la aplicación no envı́a todo el contenido

|𝐶| a una única ubicación de almacenamiento en la nube, sino que envı́a bloques
codificados con nombres anónimos a diferentes nubes). El contenido se añade al
catálogo y los usuarios finales autorizados ya pueden suscribirse al contenido pu-
blicado y dispersado (𝑆𝑢𝑏). Los usuarios finales con suscripciones autorizadas se
encargan de recuperar los contenidos mediante flujos de trabajo de recuperación
(𝑅𝑒𝑡𝑟). Esta superposición permite al servicio de pub/sub minimizar los riesgos
de las situaciones de bloqueo del proveedor y los escenarios en los que hay una
falta de control de los procedimientos crı́ticos.
Capa de flujo de metadatos

Gestor de
Painal Sub
Pub
Interfaz del Sub Interfaz del
usuario final usuario final
Servicio Pub Servicio Sub

Retr
Dy
Retr
|C|
Capa de flujo de contenido |C|
Carpeta
Carpeta
Publicación
suscripción
Simbología
Pub Publicación Dy Diseminación Sub Suscripción Retr Recuperación
Figura 3: Capa de metadatos y Pub/Sub sobrepuestas.
Las aportaciones del servicio de pub/sub se presentan a continuación.

1. Entrega colaborativa de contenidos basada en una superposición de pub/sub:
Se desarrolló un modelo 𝑅𝐸𝑆𝑇 𝑓 𝑢𝑙 de pub/sub que permite a los usuarios
finales y a los editores colaborar en el proceso de entrega de contenidos.
Simplifica la gestión de los recursos y el control de las etapas de la entrega
de contenidos. Los flujos de trabajo generados se basan en el procesamiento
multinúcleo (las aplicaciones se clonan para procesar más de un contenido a
la vez) y el transporte de flujo continuo para mitigar la sobrecarga producida
en el lado del usuario final y del editor.
2. Una estrategia de diversificación basada en la gestión de riesgos para el alma-
cenamiento multi-nube: Esta estrategia virtualiza las múltiples ubicaciones
de almacenamiento disponibles en una organización como una plataforma
de almacenamiento multi-nube unificada, que es más sencilla de gestionar
que las ubicaciones separadas. Esta diversificación se basa en un método de

colocación de contenidos que permite al servicio pub/sub realizar la asigna-
ción y localización de contenidos en esta plataforma para evitar poner todos
los huevos/contenidos en la misma cesta/ubicación de almacenamiento en la
nube. Este método distribuye los contenidos utilizando una polı́tica de eva-
luación de riesgos, que define el nivel de riesgo para cada cesta/ubicación de
la plataforma, ası́ como un conjunto de acciones de respuesta para mitigar
un conjunto reducido de riesgos expresados por los editores y las organiza-
ciones sobre la gestión de contenidos en el sistema de entrega de contenido
(CDS, por sus siglas en inglés).
3. Niveles de enmascaramiento de fallos: Se incluyen tres niveles de tolerancia a
fallos del sistema. El primer nivel tolera las fallas del servicio de los usuarios
finales y los editores. Este nivel se consigue gracias a las técnicas de dispersión
de información aplicadas a los flujos de trabajo de entrega y recuperación
(descritos en Zamná [2]). El segundo nivel tolera el desastre en el sitio de la
organización desde los usuarios finales. Este nivel se basa en un esquema de
federación en el que un conjunto de socios absorbe la carga de la organización
durante su interrupción. El último nivel tolera los efectos secundarios de
los retrasos de la geodiversidad de todos los usuarios del servicio pub/sub
mediante el almacenamiento de los contenidos en caché y su traslado a una
ubicación cerca de los usuarios finales.
En Painal, los contenidos se asignan y localizan utilizando catálogos; co-

mo resultado, solo los contenidos añadidos a un catálogo pueden ser publicados
o recuperados. Cuando una organización crea un catálogo, también define los
atributos de un conjunto de editores que pueden añadir contenidos al catálogo,
ası́ como los grupos de usuarios finales que pueden suscribirse a los conteni-
dos. La interfaz de usuario final es un componente que permite a los editores
añadir contenidos fabricados a los catálogos y dispersarlos a la plataforma de
almacenamiento multi-nube. También permite a los usuarios finales suscribirse
y recuperar los contenidos publicados. Los agentes Pub/Sub y el gestor de flujo
de trabajo son los componentes que se encargan de recibir y servir las peticiones
de las aplicaciones cliente.
Componentes del servicio de pub/sub: Agentes y clientes. El gestor de

Painal para el servicio de pub/sub se compone de un gestor de metadatos y
otro de contenidos. El gestor de metadatos se encarga de administrar los flu-
jos entre los principales componentes del servicio de pub/sub de Painal y los
clientes/agentes, mientras que el gestor de recursos que se encarga de la asigna-
ción/ubicación de contenidos y la gestión de recursos en las infraestructuras de
la federación.
A continuación se listan los componentes desarrollados para Painal.
1. Aplicación cliente - Los servicios de Painal pueden ser invocados a través

de una aplicación que contiene diferentes módulos, en donde cada módulo
corresponde a un rol (administrador, editor o usuario final). Como un usuario
Cat
Gestor de
ODA Painal
Acceso
Pub/Sub R1
Agente
Pub/Sub
PPA
Pub Gestor de Gestor de
Pub metadatos recursos
Motor de R2 Servicio y
Encubrimiento
flujo de servidor de
de fallas
trabajo pub/sub
Dy
Acceso
Tenencia Colocación de
Agente múltiple datos
UPA Manejador
Sub
Sub
Motor de R3
flujo de Sistema unidicado de
trabajo plataforma de almacenamiento
Retr
Figura 4: Los componentes y subcomponentes del servicio de Pub/Sub de Painal.
puede tener más de un rol, la aplicación de Painal habilita los módulos de

acuerdo al usuario. A continuación se describen de manera breve los módulos
desarrollados:
ODA - Es una aplicación para la configuración de los catálogos de una
organización que permite a los usuarios administradores crear catálo-
gos, asignarlos a editores y definir las polı́ticas de suscripción que deben
cumplir los usuarios finales para acceder a los datos;
PPA - Aplicación que permite a los editores obtener el listado de catálo-
gos a los que tiene acceso y permisos de publicación; por cada catálogo
encontrado se crea una carpeta y en estas carpetas el editor puede colocar
los datos que desea transferir;
UPA - Es la aplicación que usan los usuarios finales para suscribirse a los
catálogos públicos o acceder a los que el administrador de la organización
les dio acceso; esta aplicación descarga el contenido de los catálogos
(asigna una carpeta por catálogo) y los sincroniza de acuerdo con el
contenido que los editores coloquen en sus catálogos.
2. Gestor de metadatos - Es el responsable de la anonimización de los datos, ası́
como del manejo de la metadata de todos los archivos, procesos, dispositivos
de almacenamiento, catálogos y usuarios de Painal. Este gestor se compone
de los siguientes módulos:
Subsistema de servicios - Este componente se encarga de recibir las soli-
citudes de tokens3 de autorización, ası́ como de recibir las publicaciones y
3
Token (informática), también llamado componente léxico, es una cadena de carac-
teres que tiene un significado coherente en cierto lenguaje de programación. Token
de seguridad, utilizado para facilitar el proceso de autenticación de usuarios.
los pedidos de suscripción procedentes de los clientes/agentes del servicio

de pub/sub de Painal ; este subsistema es responsable de registrar las
transacciones realizadas por los editores, organizaciones y usuarios finales
(ver la Fig. 4);
Subsistema de publicación y suscripción - Este módulo se encarga de
ejecutar las órdenes de publicación y suscripción autorizadas por el sub-
sistema de servicios (ver la Fig. 4, en donde se utiliza una polı́tica basada
en atributos de rol); este módulo permite al servicio de pub/sub de Pai-
nal aceptar o rechazar ordenes de publicación y suscripción; también,
incluye un servicio de alerta que envı́a notificaciones a los editores de
contenidos y a los administradores de las organizaciones sobre las sus-
cripciones de contenidos, el cual también notifica al usuario final sobre
nuevas publicaciones;
Subsistema de tenencia múltiple (multi-tenant) - Este módulo gestiona
las propiedades de los catálogos y contenidos, ası́ como las cuentas de
los usuarios, mediante consultas a una base de datos; asegura que los
contenidos de cualquier editor, usuario final o administrador están aisla-
dos y permanecen invisibles para otros usuarios; y envı́a las solicitudes
de asignación o localización al gestor de recursos para un determinado
contenido asociado a un determinado catálogo.
3. Gestor de recursos - Es un componente crı́tico que se instala en una ins-

tancia de la nube situada en una infraestructura de nube privada. La Fig. 4
muestra un ejemplo de los flujos de metadatos entre los agentes, el servicio,
los subsistemas Pub/Sub y Multi-tenant. También, muestra cómo el gestor
de recursos atiende las solicitudes de asignación/ubicación enviadas por los
agentes y autoriza a los gestores de flujo de trabajo a transportar datos a
un sistema unificado (ULS). Detallaremos el gestor de recursos una vez que
el gestor de flujo de trabajo sea descrito en la siguiente sección.
4. Gestor de flujos de trabajo - Es el responsable de administrar los flujos de
trabajo de entrega para transportar los contenidos desde los ordenadores
de los editores a la plataforma de almacenamiento multi-cloud. Adicional-
mente, permite administrar los flujos de trabajo de recuperación para trans-
portar los contenidos desde la plataforma de almacenamiento a los orde-
nadores de los usuarios finales. Los flujos de trabajo se basan en tuberı́as
de procesamiento que incluyen dos fases básicas. La primera fase es la co-
dificación/decodificación de los contenidos, que se basa en algoritmos de
información dispersa (IDA) [20] y la segunda etapa es la distribución de los
contenidos codificados/codificados, que se basa en el streaming4 continuo
y paralelo [15]. Este gestor de flujos de trabajo es descrito de manera más
profunda en la documentación de Muyal-Zamna [2].
4
El streaming es un servicio que permite a los usuarios consumir un contenido en
lı́nea sin tener que esperar a que se descargue.
Flujos de trabajo de Painal. Como se ha descrito a lo largo de este do-

cumento, cada archivo publicado por un editor es procesado y transmitido a
diferentes nodos de almacenamiento (publicación) para después ser descargado
y reconstruido por un usuario final (recuperación). A este comportamiento se le
conoce como flujo de trabajo y, en el caso de Painal, se pueden identificar uno
para la entrega y otro para la descarga. A continuación se describen de manera
breve los dos flujos de trabajo.
Flujo de trabajo de publicación - Es el encargado de leer los contenidos que

un editor desea transmitir mediante un catálogo. Es responsable proporcio-
nar los requisitos no funcionales: reducir el contenido a procesar/almacenar
(mediante compresión); agregar control de acceso (mediante la validación de
atributos y tokens); brindar confidencialidad a los datos (mediante un algo-
ritmo de cifrado); proporcionar tolerancia a fallos (agregando redundancia a
los datos); y ejecutar las aplicaciones de manera eficiente (mediante técnicas
de paralelismo). Este flujo de trabajo incluye dos flujos de metadatos (pu-
blicación y gestión) y un flujo de contenidos (canal de dispersión).
La Fig. 5 presenta el flujo de trabajo de publicación de contenidos digitales,

en donde se observan las etapas y procesos realizados. (1) La aplicación del
editor detecta un nuevo contenido; (2) se verifican las claves de acceso del
editor con el gestor de Painal concediendo o negando el acceso; (3) se invo-
can las aplicaciones que se encargarán de cumplir con los requerimiento no
funcionales (NFR), para este sistema son los procesos de compresión, cifra-
do y dispersión; (4) los 𝑛 archivos dispersos resultantes de la aplicación de
dispersión deben de ser transferidos por la aplicación del editor, la cual se
comunica con el gestor de Painal para obtener las 𝑛 URLs relativas que se
mapean a 𝑛 ubicaciones de almacenamiento en la nube (en dónde los disper-
sos serán almacenados); y (5) la aplicación del editor inicia la transferencia
de los datos utilizando las URLs obtenidas.
Flujo de trabajo de recuperación - Está diseñado para que los usuarios fina-
les recuperen contenidos de las ubicaciones de almacenamiento en la nube
(mediante un procedimiento de decodificación multi-hilo que es ejecutado de
manera transparente para el usuario). En la Fig. 6 se muestran los pasos
realizados por este flujo: (1) la aplicación del usuario final se identifica con
el gestor de Painal y, en caso de detectar nuevos datos (agregados por un
editor ) en los catálogos, invoca al siguiente paso; (2) se obtienen las URLs de
los dispersos necesarios para reconstruir el contenido (|𝐶|), como se aplicó
un algoritmo de dispersión con redundancia solo se requiere una 𝑚 cantidad
de los 𝑛 dispersos almacenados (esta configuración usa 𝑛 = 5 y 𝑚 = 3);
(3) se inicia el proceso de descarga de los 𝑚 dispersos; (4) se ejecutan las
aplicaciones que harán cumplir los requerimientos no funcionales en el orden
inverso del utilizado en el proceso de carga (dispersión, cifrado y compre-
sión); y (5) el contenido recuperado es colocado en la carpeta seleccionada
por el usuario final.
(2) Gestor de
Painal
Interfaz del usuario final (4)
|C|
(1) IDA D5
D1
D2
D4
Carpeta
Publicación (3) D3 (5)
Figura 5: Flujo de trabajo de publicación.
Gestor de
Painal (2)
(1)
Interfaz del usuario final
D5 (5)
|C|
D1 IDA
D2
Carpeta
Publicación
D4
D3
(3) (4)
Figura 6: Flujo de trabajo de recuperación.

La gestión de los procesos de los requerimientos no funcionales para los flujos

de trabajo se basa en la utilización de patrones de procesamiento, y la etapa de
transporte se implementó utilizando las bibliotecas Curl [17], las cuales permiten
mover contenidos utilizando el protocolo de la web (HTTP). La implementación
multi-hilo de nuestros gestores de dispersión/recuperación mejora el rendimiento
de las tareas de codificación y decodificación al aprovechar los múltiples núcleos
que se encuentran habitualmente en los dispositivos actuales. Esta técnica per-
mite que el gestor reduzca la sobrecarga de codificación, lo que hace factible
la introducción de un esquema tolerante a fallos en el lado del editor de con-
tenidos/usuario final. La implementación del proceso de entrega de contenidos
como flujo continuo permite al gestor evitar la escritura de bloques en los discos
locales.
2.2. Sistema federado para la distribución de contenidos y

administración de requerimientos no funcionales
En esta sección se describen los principios de diseño de FedCDS, la arquitec-
tura y los principales componentes del sistema, ası́ como los esquemas basados
en patrones de paralelismo mediante contenedores para preparar/recuperar los
datos cuando se cargan/descargan a través del FedCDS y el gestor de Painal.
Estos esquemas gestionan los requisitos no funcionales seleccionados por las or-
ganizaciones para cumplir con las regulaciones impuestas por las organizaciones
y los gobiernos.
Figura 7: Arquitectura detallada del sistema federado [3] para la distribución de

contenidos con Muyal-Painal.
Arquitectura del sistema. La Fig. 7 muestra la arquitectura detallada y los

principales componentes del FedCDS de Painal para un escenario compuesto
por tres hospitales diferentes (organizaciones), lo cual permite observar la comu-
nicación entre los servicios apilados de cada organización. Cada hospital (orga-
nización) despliega dos tipos de servicios: servicios federados y servicios locales.
El objetivo de distinguir estos dos tipos de servicios es que cada organización
tiene el control de sus datos y recursos, pero, al mismo tiempo, algunos servicios
permiten a las organizaciones compartir recursos y datos de forma transparen-
te y segura. A través de estos servicios, las organizaciones tienen acceso a los
recursos y datos disponibles en otras organizaciones (imágenes médicas o histo-

rias clı́nicas). Para ello, los servicios federados para cada organización son los
siguientes:
Interfaz de acceso (Front-End ) - Capa a través de la cual los administradores,
editores y usuarios finales de una organización y participantes de la federa-
ción pueden acceder a los servicios; dispone de una interfaz de programación
de aplicaciones (API) que permite la interacción con otros participantes, ası́
como la validación de tokens y un proxy5 para redirigir las peticiones a los
servicios de los niveles inferiores o disponibles en otras organizaciones de la
federación;
Autenticación - Invoca al gestor de Painal para validar el acceso de los usua-
rios finales, que son miembros de la federación, o una organización especı́fica;
Pub/Sub - Servicio encargado de gestionar las solicitudes de publicación y
suscripción de datos (imágenes o historias clı́nicas o historias clı́nicas), catá-
logos, fuentes y repositorios de los usuarios pertenecientes a la federación.
Los servicios locales se encargan de gestionar el sistema dentro de cada orga-

nización, incluida la gestión de los usuarios internos, ası́ como los datos que se
manejan en la organización. La idea de estos servicios es que cada organización
pueda gestionar sus catálogos de datos de forma independiente a los publicados
en la federación. En el caso de que los usuarios quieran publicar sus datos en
la federación, podrán hacerlo con solo cambiar el estado del catálogo de “lo-
cal/privado” a “federado” o, igualmente, dando acceso solo a un determinado
grupo de usuarios de la federación. Dentro de los servicios locales se incluyen tres
capas para gestionar la autenticación de usuarios y tokens de la organización,
gestionar las publicaciones y suscripciones y gestionar el almacenamiento, ası́
como los metadatos asociados a estos servicios.
El intercambio de mensajes y metadatos entre los miembros de la federa-
ción se efectúa a través de API REST, mientras que los datos se transportan
utilizando una red de entrega de contenidos del servicio de pub/sub de Painal.
Los esquemas de preparación de datos [12] se despliegan para añadir los NFR
a los datos antes de ser transportados. Estos esquemas procesan los datos para
añadir propiedades como la rentabilidad, la fiabilidad y la seguridad para ser
compartidos con los miembros de la federación.
3. Mecanismo de usabilidad costo-beneficio para el

almacenamiento y transporte de datos
La arquitectura de malla para el almacenamiento de datos se basa en una
estructura de almacenamiento que se asocia para gestionar nodos de almacena-
miento (SN, por sus siglas en inglés). Los SN son sistemas de almacenamiento
5
Es un servidor o programa informático que sirve de intermediario en las peticiones
de recursos que realiza el usuario final y el servidor fuente, almacenando una copia
caché de los mismos para acelerar su suministro.
tradicionales que incluyen sistemas como la entrega/recuperación de archivos,

balanceadores de carga, distribución de datos y los sistemas de colocación, ası́
como los microservicios para atender los requisitos no funcionales (NFR). Los
componentes de los SNs se encapsulan en contenedores virtuales, brindándoles
la caracterı́stica de portabilidad. En los servicios de almacenamiento confiables
sin servidor (SeRSS) de Painal, estos componentes se gestionan utilizando una
estructura de almacenamiento, que convierte las SNs en microservicios6 en for-
ma de redes de almacenamiento descentralizadas P2P. En los microservicios de
fiabilidad SeRSS, Painal implementa una técnica de codificación/decodificación
de datos basada en el algoritmo IDA [22], [20], descrita a mayor profundidad en
[2]. Los microservicios de seguridad implementan servicios de criptografı́a para
garantizar cualquier integridad, confidencialidad o autenticación, mientras que
los microservicios de patrones paralelos mejoran el rendimiento de los microser-
vicios descritos anteriormente.
La idea básica es que las organizaciones puedan elegir los parámetros de al-
macenamiento a alto nivel (es decir, el número de nodos de almacenamiento
necesarios para una solución determinada) y los parámetros NFR. De esta ma-
nera, se puede utilizar esta información para construir de manera automática
un sistema de almacenamiento fiable en forma de sistema P2P sin servidor que
puede ser consumido por los usuarios finales como un servicio que puede ser
desplegado en infraestructuras heterogéneas.
3.1. Servicios de almacenamiento confiables sin servidor: Principios

de diseño
En esta sección se describen los componentes de una estructura de alma-
cenamiento que se asocian a los SN, ası́ como un conjunto de microservicios
que proporcionan caracterı́sticas no funcionales como la fiabilidad seguridad y
eficiencia. Por último, se presentan los componentes para construir sistemas de
almacenamiento en forma de un sistema P2P.
Construcción de estructuras de almacenamiento confiables. Las estructuras de

almacenamiento gestionadas en los servicios SeRSS de Painal permiten a las
organizaciones almacenar y gestionar los datos de manera eficiente y confiable.
Cada estructura de almacenamiento se despliega como un contenedor virtual.
Esto añade la caracterı́stica de portabilidad a las estructuras construidas, per-
mitiendo a las organizaciones mover la estructura de almacenamiento a través
de diferentes infraestructuras. La Fig. 8 muestra la representación en pila de una
estructura de almacenamiento. Estas estructuras implementan dos componentes
principales para gestionar los datos dentro de una organización: i) un sistema de
almacenamiento; y ii) un esquema de entrega.
El sistema de almacenamiento se encarga de gestionar la colocación de los
datos a través de los recursos de almacenamiento de una organización. En este
6
Piezas de software independientes y portátiles que pueden acoplarse a otros micro-
servicios.
Esquema de entrega
Sistema de almacenamiento
Administrador de esferas
Colocación de datos
Balanceador de carga
Distribuidor Nodo
Figura 8: Representación conceptual de una estructura de almacenamiento.
contexto, el método de colocación de datos que se ha implementado se basa en la

metáfora de las esferas en los contenedores (balls-into-bins) [22], donde los datos
se gestionan como esferas que se asignan a un conjunto de contenedores (recursos
de almacenamiento). Para lograr este objetivo, el sistema de almacenamiento
implementa un gestor de esferas encargado de gestionar los metadatos de los
datos que llegan a la estructura de almacenamiento. Los datos se entregan a un
sistema de colocación de datos, que llama a un servicio de balanceo de carga
basado en el algoritmo de dos opciones (two choices) [1], [22] para crear una
distribución justa de los segmentos entre las ubicaciones de almacenamiento. Un
distribuidor se encarga de asignar los segmentos producidos en las ubicaciones
de almacenamiento.
El esquema de distribución permite el intercambio de datos entre diferentes
estructuras de almacenamiento desplegadas en diferentes entornos. Estos esque-
mas imponen el cumplimiento de los NFR (por ejemplo, la disponibilidad y la
eficiencia) en la gestión de datos impuestos por los gobiernos y las organizaciones
para la gestión de datos sensibles (i.e., NIST [16] , COBIT5 [9], ISO27001-7 [5],
y normas mexicanas de gestión de datos [18], [25]). Los esquemas de entrega se
manejan como microservicios de NFR basados en el algoritmo de IDA para la to-
lerancia a fallos, esquemas de preparación para resolver problemas de seguridad
(por ejemplo, la verificación de la integridad usando el algoritmo SHA3) y patro-
nes paralelos para mejorar la eficiencia de los componentes de las estructuras de
almacenamiento. El microservicio de confiabilidad codifica los datos utilizando el
conocido algoritmo IDA descrito en [22], [20]. Además, se aplican microservicios
de seguridad a los datos para verificar su integridad, mecanismos de control de
acceso para permitir que solo los usuarios autorizados accedan a los datos (por
ejemplo, utilizando técnicas de sobres digitales) y confidencialidad mediante el
cifrado de los datos. Los componentes de la estructura de almacenamiento, inclui-
dos los microservicios de NFR, pueden desplegarse como patrones paralelos para
mejorar la eficiencia en el procesamiento de los datos. Estos patrones paralelos
se implementan como patrones de contenedores virtuales y pueden configurarse
en cada esquema de entrega. Estos patrones son descritos a profundidad en el
servicio de la plataforma Zamna, descrita en [2].
La creación de sistemas de almacenamiento P2P sin servidor en una malla pa-

ra el almacenamiento de datos permite a las organizaciones la posibilidad de
construir soluciones de almacenamiento basadas en sus recursos disponibles en
cualquiera de los recursos locales, comunitarios o la nube. Además, las organi-

zaciones pueden elegir los parámetros a alto nivel (es decir, el número de nodos
de almacenamiento necesarios para una solución determinada) y el servicio de
SeRSS de Painal construye automáticamente el sistema de almacenamiento P2P
sin servidor. En este contexto, la infraestructura de la organización se gestiona
como una malla de recursos. La Fig. 9 muestra una representación conceptual
de las soluciones de almacenamiento desplegadas con esta arquitectura de malla.
Como se puede observar, sobre la malla se despliegan diferentes soluciones de
almacenamiento. Las soluciones de almacenamiento se construyeron desplegan-
do un conjunto de estructuras de almacenamiento (SS, por sus siglas en inglés)
como P2P. Estas soluciones de almacenamiento utilizan tablas hash distribuidas
(DHT). Como se puede observar en la Fig. 9, se pueden desplegar diferentes so-
luciones sobre la misma malla de recursos. Estas soluciones pueden diferir entre
sı́ en cuanto al número de nodos de la estructura, los requisitos no funcionales
gestionados por las estructuras de almacenamiento y los recursos utilizados.
Simbología
Solución de
Nodo almacenamiento
Infraestructura
Figura 9: Representación conceptual de diferentes mallas de almacenamiento uti-

lizadas para gestionar datos de manera confiable.
La malla de recursos se construye partiendo los nodos de almacenamiento

fı́sico (ps, por sus siglas en inglés) en un conjunto de particiones virtuales (vp,
por sus siglas en inglés). Estas particiones virtuales son básicamente divisio-
nes lógicas de los nodos de almacenamiento con una porción limitada de los
recursos (memoria, CPU y capacidad de almacenamiento) de la infraestructura
fı́sica (ps). En esta arquitectura, la solución se despliega en una malla de nodos
de almacenamiento (M). Esta M está compuesta por un conjunto de nodos de
almacenamiento fı́sico 𝑝𝑠 (eje horizontal 𝑥 de la malla), donde cada 𝑝𝑠 está di-
vidido en 𝑦 particiones denominadas almacenamiento virtual 𝑣𝑝 (eje vertical 𝑦
de la malla) y se define como la malla presentada en la Fig. 10.
En donde 𝑞 es el número de particiones virtuales en los nodos de almace-
namiento y 𝑝 es el número de nodos de almacenamiento fı́sicos. Ası́, el número
de recursos disponibles en la malla (𝑀 ) es 𝑝 Ö 𝑞. Cada celda de la malla es un
recurso de almacenamiento disponible, donde un 𝑆𝑁 virtual puede desplegarse
Figura 10: Ejemplo de malla de almacenamiento.
como un contenedor virtual que contiene una estructura de almacenamiento. Un

SN en la malla puede adoptar cualquiera de los siguientes roles:
Rol de servicio (ser) - para atender las solicitudes realizadas por usuarios
finales;
Rol de gestor (mgr) - se encarga de ejecutar las tareas de almacenamiento
(asignación, localización y equilibrio de carga) y de añadir los requisitos no
funcionales a los datos;
Rol de nodo (node) - Se encarga de preservar datos.
Tenga en cuenta que al menos un servicio ser y un gestor mgr deben estar
asignados en la malla. La selección de los nodos de servicio y gestor son realizados
durante el diseño y construcción.
Descripción de los componentes utilizados para el desarrollo del prototipo. La

arquitectura de malla y los componentes de la estructura de almacenamiento se
implementaron como un prototipo desarrollado principalmente en lenguaje de
programación C. El componente para la dispersión de datos (IDA) utilizado en
la estructura de almacenamiento también se ha implementado utilizando dicho
lenguaje. El intercambio de datos entre los nodos de almacenamiento virtual
se realiza a través de una red de entrega de contenidos del servicio de publica-
ción/suscripción de Painal. En la malla, los nodos de almacenamiento virtual
de una solución de almacenamiento se gestionan como una red P2P mediante
un algoritmo de tabla hash distribuida (DHT), llamado Chord, implementado
en lenguaje Python. Los nodos de almacenamiento virtual se despliegan como
contenedores virtuales utilizando la plataforma de contenedores Docker. Estos
contenedores virtuales añaden portabilidad a los nodos, ya que, en los compo-
nentes del almacenamiento, la estructura se encapsula en el contenedor junto
con sus dependencias (es decir, bibliotecas, paquetes, SO, variables de entorno),
lo que permite el despliegue de los nodos en diferentes infraestructuras.
4. Conclusiones
El presente capı́tulo describió la herramienta “Muyal-Painal: Servicio para
el transporte y almacenamiento de datos médicos”, que forma parte del Proyecto
ProNacEs-Pronaii número 41756 titulado “Plataforma tecnológica para la ges-
tión, aseguramiento, intercambio y preservación de grandes volúmenes de datos
en salud y construcción de un repositorio nacional de servicios de análisis de

datos de salud”. Painal permite a los profesionales de la salud compartir datos,
información y sistemas de e-salud en forma inter-institucional (local) e intra-
institucional (un conjunto federado de organizaciones). Permite crear, de forma
automática y sin intervención de personal de la salud, sistemas de logı́stica para el
almacenamiento y distribución de datos de salud, imagenologı́a y datos de senso-
res y áreas de intercambio federadas intra/inter-institucionales. Las evaluaciones
realizadas y publicadas en [3], [4] muestran que Painal permite la sincronización
automática de datos, reduciendo los tiempos de respuesta, ası́ como los costos
de envió y almacenamiento de información, mejorando la experiencia de servicio
para los usuarios finales.
5. Agradecimientos
Este trabajo ha sido parcialmente financiado por el proyecto No. 41756 ti-
tulado “Plataforma tecnológica para la gestión, aseguramiento, intercambio y
preservación de grandes volúmenes de datos en salud y construcción de un repo-
sitorio nacional de servicios de análisis de datos de salud” del fondo PRONACES-
CONACYT.
Bibliografı́a
[1] Roberto Beraldi, Hussein Alnuweiri y Abderrahmen Mtibaa. “A power-of-
two choices based algorithm for fog computing”. En: IEEE Transactions
on Cloud Computing 8.3 (2018), págs. 698-709.
[2] Diana Carrizales-Espinoza, JL Gonzalez-Compean y Miguel Morales-Sandoval.
“Zamna: a tool for the secure and reliable storage, sharing, and usage of
large data sets in data science applications”. En: 2022 IEEE Mexican Inter-
national Conference on Computer Science (ENC). IEEE. 2022, págs. 1-8.
[3] Diana Carrizales-Espinoza et al. “A Federated Content Distribution Sys-
tem to Build Health Data Synchronization Services”. En: 2021 29th Eu-
romicro International Conference on Parallel, Distributed and Network-
Based Processing (PDP). 2021, págs. 1-8. doi: 10.1109/PDP52278.2021.
00011.
[4] Diana Carrizales-Espinoza et al. “SeRSS: a storage mesh architecture to
build serverless reliable storage services”. En: 2022 30th Euromicro Inter-
national Conference on Parallel, Distributed and Network-based Processing
(PDP). 2022, págs. 88-91. doi: 10.1109/PDP55904.2022.00022.
[5] Sanskriti Choubey y Astitwa Bhargava. “Significance of ISO/IEC 27001 in
the implementation of governance, risk and compliance”. En: International
Journal of Scientific Research in Network Security and Communication 6.2
(2018), págs. 30-33.
[6] Lawrence Chung et al. Non-functional requirements in software enginee-
ring. Vol. 5. Springer Science & Business Media, 2012.
[7] Frank Frank Edward Dabek. “A distributed hash table”. Tesis doct. Mas-
sachusetts Institute of Technology, 2005.
[8] Chun-Ping Deng et al. “Organizational agility through outsourcing: Roles
of IT alignment, cloud computing and knowledge transfer”. En: Interna-
tional Journal of Information Management 60 (2021), pág. 102385.
[9] Yusuf Durachman et al. “IT security governance evaluation with use of
COBIT 5 framework: A case study on UIN Syarif Hidayatullah library
information system”. En: 2017 5th International Conference on Cyber and
IT Service Management (CITSM). IEEE. 2017, págs. 1-5.
[10] Roy T. Fielding et al. “Reflections on the REST architectural style and
”principled design of the modern web architecture”(impact paper award)”.
En: Proceedings of the 2017 11th Joint Meeting on Foundations of Softwa-
re Engineering, ESEC/FSE 2017, Paderborn, Germany, September 4-8,
2017. Ed. por Eric Bodden et al. ACM, 2017, págs. 4-14. doi: 10.1145/
3106237.3121282.
[11] José Luis González et al. “SkyCDS: A resilient content delivery service
based on diversified cloud storage”. En: Simulation Modelling Practice and
Theory 54 (2015), págs. 64-85.
[12] JL Gonzalez-Compean et al. “Fedids: a federated cloud storage architec-
ture and satellite image delivery service for building dependable geos-
patial platforms”. En: International journal of digital earth 11.7 (2018),
págs. 730-751.
[13] Haryadi S Gunawi et al. “Why does the cloud stop computing? lessons
from hundreds of service outages”. En: Proceedings of the Seventh ACM
Symposium on Cloud Computing. 2016, págs. 1-16.
[14] B Hayes. Cloud Computing (CC) Communications of the ACM, 51 (7).
2008.
[15] Daniel Higuero et al. “HIDDRA: a highly independent data distribution
and retrieval architecture for space observation missions”. En: Astrophysics
and Space Science 321.3 (2009), págs. 169-175.
[16] Ahmed Ibrahim et al. “A security review of local government using NIST
CSF: a case study”. En: The Journal of Supercomputing 74.10 (2018),
págs. 5171-5186.
[17] The multiprotocol file transfer library. libcurl - the multiprotocol file trans-
fer library. Available at: http://curl.haxx.se/libcurl, Last accessed:
2022-10-27. Sep. de 2022.
[18] SUBSECRETARÍA DE INTEGRACIÓN DEL SECTOR SALUD MA-
KI ESTHER ORTIZ DOMINGUEZ. “NORMA Oficial Mexicana NOM-
024-SSA3-2010, Que establece los objetivos funcionales y funcionalidades
que deberán observar los productos de S istemas de Expediente C lı́nico
Electrónico para garantizar la interoperabilidad, procesamiento, interpre-
tación, confidencialidad, seguridad y uso de estándares y catálogos de la
información de los registros electrónicos en salud. Al margen un sello con
el Escudo Nacional, que dice: Estados Unidos Mexicanos.-Secretarı́a de
Salud.” En: ().
[19] M Malik. “Internet of Things (IoT) Healthcare Market by Component

(Implantable Sensor Devices, Wearable Sensor Devices, System and Soft-
ware), Application (Patient Monitoring, Clinical Operation and Workflow
Optimization, Clinical Imaging, Fitness and Wellness Measur”. En: Allied
Market Research (2016).
[20] Ricardo Marcelı́n-Jiménez et al. “On the complexity and performance of
the information dispersal algorithm”. En: IEEE Access 8 (2020), págs. 159284-159290.
[21] Peter Mell, Tim Grance et al. “The NIST definition of cloud computing”.
En: (2011).
[22] Pablo Morales-Ferreira et al. “A data distribution service for cloud and
containerized storage based on information dispersal”. En: 2018 IEEE
Symposium on Service-Oriented System Engineering (SOSE). IEEE. 2018,
págs. 86-95.
[23] Justice Opara-Martins, Reza Sahandi y Feng Tian. “Critical review of
vendor lock-in and its impact on adoption of cloud computing”. En: Inter-
national Conference on Information Society (i-Society 2014). IEEE. 2014,
págs. 92-97.
[24] David Reinsel-John Gantz-John Rydning, J Reinsel y J Gantz. “The digi-
tization of the world from edge to core”. En: Framingham: International
Data Corporation 16 (2018).
[25] SECTOR SALUD, SUBSECRETARIA DE PREVENCION Y PROMO-
CION DE y CONSEJO DE SALUBRIDAD GENERAL. “NORMA OFI-
CIAL MEXICANA NOM-024-SSA3-2012, SISTEMAS DE INFORMA-
CION DE REGISTRO ELECTRONICO PARA LA SALUD. INTER-
CAMBIO DE INFORMACION EN SALUD CONSIDERANDOS”. En:
().
[26] Dante D Sánchez-Gallegos et al. “From the edge to the cloud: A conti-
nuous delivery and preparation model for processing big IoT data”. En:
Simulation Modelling Practice and Theory 105 (2020), pág. 102136.
∑𝑛𝑖=0 𝑤𝑖 𝑥𝑖 − 𝜃𝑖 𝑥 = (𝑥1 . . . 𝑥𝑛 )
𝑤 = (𝑤1 . . . 𝑤𝑛 ) 𝜃𝑖
●
●
●
●
●
.mayoría de los países, según un estudio de la oms

Procesamiento de datos médicos cualitativos
para el análisis y modelado en aprendizaje
automático
Edwin Aldana-Bobadilla1[0000−0001−8315−1813]
Alejandro Molina-Villegas2[0000−0001−9398−8844]
Hiram Galeana-Zapién3[0000−0002−8449−9077]
Karina Gazca-Hernández3
1
Conacyt-Centro de Investigación y de Estudios Avanzados del I.P.N. (Cinvestav),
Victoria 87130, Mexico
[email protected]
2
Conacyt-Centro de Investigación en Ciencias de Información Geoespacial
(Centrogeo), Mérida 97302, Mexico
[email protected]
3
Centro de Investigación y de Estudios Avanzados del I.P.N. (Cinvestav), Victoria
87130, Mexico
{hgalena,karina.gazca}@cinvestav.mx
Resumen La coyuntura tecnológica actual ha hecho posible almacenar,

distribuir y procesar grandes y variados tipos de datos procedentes de
muchas actividades del acontecer humano en diferentes dominios. El do-
minio clı́nico es, sin lugar a dudas, un escenario en el cual este hecho se
hace latente y en el que, por su naturaleza, conviven diferentes fuentes de
datos, tanto estructurados como no estructurados, alrededor de los pa-
cientes. Muchos de estos datos no son susceptibles de análisis numérico
directo –dada su naturaleza cualitativa–, por lo que siempre es requeri-
do realizar tareas de transformación que permitan llevarlos a un espacio
en el que dicho análisis sea posible. Este trabajo hace un recorrido por
los diferentes tipos de datos no numéricos en el contexto clı́nico y las
alternativas para lograr una transformación que permita extraer su valor
informativo en aras de realizar análisis numérico para el apoyo a la toma
de decisión. Dada la importancia de dicha transformación en la efectivi-
dad de los modelos obtenidos, este trabajo tiene como objetivo servir de
guı́a para ayudar a la selección de las transformaciones más adecuadas
en función de los tipos de datos del problema. Se presentan varios casos
de estudio en los que se aplican diferentes técnicas de transformación
y extracción de caracterı́sticas para texto, imágenes y señales fisiológi-
cas que, al ser utilizadas por modelos de predicción, mostraron un buen
desempeño.
Palabras Clave: Datos Categóricos · Datos no Estructurados · Extrac-

ción de Caracterı́sticas.
Datos Médicos No Estructurados 195
1. Introducción
Los datos del historial clı́nico de un paciente son un recurso fundamental en

la práctica clı́nica y en el ámbito de ciencias de la salud e investigación médi-
ca. Dichos datos son recolectados por los profesionales de la salud durante los
procesos de ingreso hospitalario, diagnóstico y atención del paciente hasta la fi-
nalización del tratamiento. Dicho historial clı́nico está conformado generalmente
por diversos tipos de datos, entre los que se encuentran: a) datos recopilados por
el médico a través de preguntas al paciente; b) datos recabados por el médico co-
mo resultado de una exploración fı́sica, medición de signos vitales y resultados de
análisis de laboratorio; c) resumen de sı́ntomas y diagnósticos posibles identifica-
dos con base en la exploración previa; y d) tratamiento recomendado al paciente.
En este contexto, la evolución de las tecnologı́as y ciencias computacionales ha
permitido el desarrollo de sistemas como el expediente clı́nico electrónico (EMR,
por su siglas en inglés) con el fin de organizar y almacenar grandes volúme-
nes de datos clı́nicos en un ambiente hospitalario. Como su nombre lo indica,
el EMR es un sistema de gestión de datos hospitalarios que se desarrolla bajo
criterios y recomendaciones internacionales que buscan garantizar la disponi-
bilidad, confidencialidad e integridad de los datos (e.g. norma oficial mexicana
NOM-024). Entre los datos incluidos en un EMR se tienen datos administrativos
y demográficos, diagnósticos, tratamientos, prescripciones, resultados de análisis
de laboratorio, datos de monitoreo fisiológico, entre muchos otros. Muchos de los
análisis en la práctica médica están asociados a variables numéricas continuas en
aras de proveer evaluaciones precisas y confiables acerca del estado o condicio-
nes de un paciente. Por ejemplo, en [20] se argumenta el impacto positivo de los
probióticos en el control metabólico de los pacientes con diabetes tipo 2 con base
en variables numéricas, como el ı́ndice de masa corporal, los niveles de coleste-
rol total, colesterol bueno y malo, triglicéridos, glucosa plasmática en ayunas,
niveles de insulina en ayunas, presión arterial sistólica y diastólica. En [18] se
diseñan modelos de regresión para determinar la relación de prevalencia entre la
agresividad tumoral y los cambios en la composición corporal, considerando el
porcentaje de masa magra, masa grasa, ángulo de fase, resistencia, reactancia,
la leptina plasmática, cambios en la composición corporal entre otros.
Sin embargo, la práctica médica también puede incluir variables que repre-
sentan: 1) la ocurrencia de un evento (e.g. infección, enfermedad, reingreso hos-
pitalario, deceso) y el grado de afectación de una enfermedad de acuerdo con
un conjunto de categorı́as predefinidas (e.g. alto, medio, bajo); 2) la pertenencia
del paciente a uno de dos o más grupos mutuamente excluyentes (e.g. género,
etnia, escolaridad, etc.); y 3) la transformación de una variable continua para
establecer niveles predefinidos que simplifiquen su análisis (e.g. rango de edad,
niveles de insulina, niveles de presión, etc.). Estas variables son ampliamente
conocidas como variables categóricas, las cuales representan diferentes niveles de
medición –nominal y ordinal– con importantes implicaciones en su interpretación
y análisis. Estas variables hacen parte comúnmente de datos que corresponden a
estructuras predefinidas que representan entidades u objetos de dominio (e.g. pa-
196 Aldana-Bobadilla et al.
ciente, consultorio, médico), por lo que reciben el nombre de datos estructurados.

Por otro lado, la tecnologı́a computacional (hardware y software) ha permitido
la generación, almacenamiento, transmisión y procesamiento de imágenes, docu-
mentos de texto, videos, audios, entre otros, los cuales no están supeditados a
una estructura tabular que permita su análisis numérico de manera directa. En
virtud de permitir dicho análisis, se ha recurrido a diferentes técnicas de áreas
como el procesamiento digital de imágenes [47], el procesamiento de señales [44] y
el procesamiento de lenguaje natural [36]. El dominio clı́nico es, sin duda alguna,
una fuente creciente de este tipo de datos denominados no estructurados.
El resto del capı́tulo está organizado de la siguiente manera. En la Sección
2 se presenta una descripción de los datos categóricos y las alternativas para
codificarlos en valores susceptibles al análisis numérico. Posteriormente, en la
Sección 3 se presentan las principales estrategias existentes para el procesamiento
de datos no estructurados. Finalmente, las conclusiones del capı́tulo se presentan
en la Sección 4.
2. Distinguiendo entre datos categóricos y numéricos
Cuando los sı́mbolos (números, letras o cadenas de caracteres) que represen-

tan el valor de una variable del paciente se usan exclusivamente para clasificarlo,
se dice que dicha variable es una medición en su nivel más débil. Estos números o
sı́mbolos constituyen lo que comúnmente se denomina escala nominal [34]. Esta
escala se presenta en situaciones como aquellas en las que un diagnóstico médico
identifica a un paciente como diabético o hipertenso, el paciente es asignado a un
grupo étnico particular o cuando dicho paciente es asignado a una nacionalidad
o área geográfica en virtud de su origen. Si se usan números (1, 2, 3, ..., 𝑛) en una
escala nominal, es incoherente sumar o restar sus valores, ya que dicha operación
no tiene sentido en el contexto de lo que éstos representan: clases o grupos. Por
lo tanto, la única medida estadı́stica descriptiva admisible para este tipo de es-
cala es la moda y la única relación entre dos posibles valores es la igualdad (=).
En las secciones subsiguientes se presentan diferentes técnicas para procesar y
analizar datos en escala nominal.
Puede suceder que los valores (sı́mbolos) de una variable asociada al paciente
no solo representen categorı́as, sino que, además, exista una relación de orden
o precedencia entre ellas. Por ejemplo, una variable representando el nivel de
escolaridad de un paciente con valores del conjunto {primaria, secundaria, pre-
paratoria, licenciatura, posgrado} induce una relación de orden. Este tipo de
variable es conocida como escala ordinal [26]. La relación de igualdad (=) entre
dos posibles valores se mantiene, pero ahora es posible definir una relación deno-
tada por (>) para indicar que un valor ’supera’ a otro o (<) para indicar que un
valor ’no supera’ a otro. Por ejemplo 𝑝𝑜𝑠𝑔𝑟𝑎𝑑𝑜 > 𝑙𝑖𝑐𝑒𝑛𝑐𝑖𝑎𝑡𝑢𝑟𝑎 > 𝑝𝑟𝑒𝑝𝑎𝑟𝑎𝑡𝑜𝑟𝑖𝑎
o 𝑝𝑟𝑒𝑝𝑎𝑟𝑎𝑡𝑜𝑟𝑖𝑎 < 𝑙𝑖𝑐𝑒𝑛𝑐𝑖𝑎𝑡𝑢𝑟𝑎 < 𝑝𝑜𝑠𝑔𝑟𝑎𝑑𝑜. Si cada valor es asignado a un valor
numérico o puntuación donde el orden se preserve, el estadı́stico más apropiado
para este tipo de escala será la mediana.
Cuando el valor de la variable induce un orden pero, además, la diferencia

entre dos valores tiene sentido, estamos ante una escala más fuerte que la ordinal,
usualmente conocida como escala de intervalo [34]. Un ejemplo clásico de este
tipo de escala es, por ejemplo, la temperatura corporal de un paciente medida
en grados Celsius ( ∘ 𝐶) o Fahrenheit ( ∘ 𝐹 ). En este tipo de escala, el valor cero
es relativo, esto significa que el cero no siempre representa la ausencia de la
propiedad que se está midiendo. Por ejemplo, la temperatura de congelación de
0 ∘ 𝐶 no significa ausencia de temperatura; este cero es relativo a la unidad de
medida, ya que el mismo valor de temperatura puede ser expresado como 32 ∘ 𝐹 .
Una propiedad importante de esta escala es que las razones de las diferencias
de valores (intervalo) son independientes de la unidad de medida y del punto
(30∘ 𝐶−10∘ 𝐶) (86∘ 𝐹 −50∘ 𝐹 )
cero, como por ejemplo (100 ∘ 𝐶−30∘ 𝐶) = (212∘ 𝐹 −86∘ 𝐹 ) = 0,28. Comparada con la
escala nominal y ordinal, la escala de intervalo es formalmente cuantitativa, por

lo que puede ser descrita a través de estadı́sticos como la media y la desviación
estándar. La escala de intervalo es una condición necesaria, pero no suficiente,
para realizar pruebas paramétricas.
Para valores cuyas unidades de medida poseen un cero absoluto, la razón en-
tre cualesquiera dos valores es independiente de la unidad de medida. Por ejem-
plo, si la razón del peso de dos pacientes es 65𝑘𝑔
70𝑘𝑔 = 0,93, esta razón se conserva
cuando el peso se expresa en libras (lb) 143,3𝑙𝑏
154,3𝑙𝑏 = 0,93. Ası́ mismo, la multipli-
cación de un valor de la escala por un número 𝑐 conserva sus proporciones e in-
terpretación independientemente de la unidad de medida: 2(65𝑘𝑔) = 2(143,3𝑙𝑏).
Lo anterior no es posible para valores ordinales y de intervalo. Este tipo de es-
calas admite todas las operaciones aritméticas y puede ser descrita a través de
estadı́sticos como la media, la mediana y la desviación estándar.
Las anteriores consideraciones son muy importantes a la hora del análisis, es-
pecialmente cuando se plantean modelos que incluyen operaciones entre diferen-
tes variables. Como hemos mencionado anteriormente, el dominio clı́nico incluye
frecuentemente datos en escalas nominales y ordinales que, por su naturaleza,
no pueden ser usados ni interpretados como números de manera directa. En las
siguientes subsecciones se describen algunas técnicas que permiten transformar
datos nominales u ordinales con el propósito de inducir algunas propiedades
numéricas en ellos.
2.1. Codificación
Una variable de escala nominal u ordinal induce 𝑘 categorı́as que pueden
ser transformadas en una secuencia de 𝑘 − 1 variables. Retomando el ejemplo
de la escolaridad del paciente, esta variable es codificada como una secuencia
de cuatro variables binarias, como se ilustra en la Tabla 1. Estas variables son
denominadas variables dummy y pueden ser usadas como variables predictoras
en modelos de regresión o clasificación [13]. Los valores de dichas variables (0,1)
inducen un espacio ortogonal en el que la suma, la resta y el cálculo de distancia
son posibles. Obsérvese que no es necesaria la variable primaria, ya que con las
cuatro variables restantes codificadas siempre será posible inferirla (cuando las
Tabla 1: Ejemplo de codificación de una variable categórica con 𝑘 = 5

Valor original Variables dummy
secundaria preparatoria licenciatura posgrado
primaria 0 0 0 0
secundaria 1 0 0 0
preparatoria 0 1 0 0
licenciatura 0 0 1 0
posgrado 0 0 0 1
cuatro variables son cero). Matemáticamente, es conveniente hacerlo ası́ porque,

de lo contrario, se estará introduciendo una variable que queda explicada por
las otras, generando un problema de colinealidad que podrı́a inducir matrices
singulares que impedirı́an la solución del problema.
Es de notar que esta codificación pudiera resultar computacionalmente costo-
sa en función del número de categorı́as o niveles de la variables (e.g. nombres de
estados de un paı́s, catálogo de enfermedades, etc.), en cuyo caso es posible recu-
rrir a métodos como aquellos basados en hashing que mapean cada valor de la va-
riable a un valor entero (hash), el cual es, a su vez, transformado en un valor ente-
ro que representa un código más compacto de la caracterı́stica usando aritmética
modular [46]. Por ejemplo, podemos aplicar una función hash (e.g. md5) al va-
lor de una categorı́a ası́: 𝑚𝑑5(𝑑𝑖𝑎𝑏𝑒𝑡𝑒𝑠) = 𝑐35𝑏49𝑑𝑎1𝑏6𝑑𝑑679𝑎48𝑑67𝑓 456𝑏𝑐7𝑎𝑎𝑓 .
Si nuestro catálogo de categorı́as es, por ejemplo, del orden de cientos, lo ideal
serı́a mapear ciertas enfermedades a una misma categorı́a con el fin de obtener
un catálogo más compacto. Sea 𝑟 = 16 el número deseado de categorı́as en nues-
tro nuevo catálogo; entonces, 𝑐35𝑏49𝑑𝑎1𝑏6𝑑𝑑679𝑎48𝑑67𝑓 456𝑏𝑐7𝑎𝑎𝑓 mod 𝑟 será
el código nuevo asignado a la categorı́a de diabetes que, en este caso, correspon-
de a 3. Aunque este método reduce el espacio de las variables codificadas, éste
puede inducir otros problemas como aquellos causados por posibles colisiones en
la generación de los valores hash.
Existen otros enfoques de codificación como aquellos basados en los datos de
salida o variable a predecir, razón por la cual reciben el nombre de métodos de
codificación supervisados. Este tipo de codificación es apropiada cuando la varia-
ble a ser codificada tiene muchos valores posibles o, inclusive, cuando aparecen
nuevos valores después de la fase de obtención del modelo (entrenamiento). Los
códigos postales son un buen ejemplo, por ejemplo, en el caso de México hay
aproximadamente 33,000 códigos postales. Ante esta cardinalidad, es obvio que
una codificación basada en variables dummy resulta computacionalmente inefi-
ciente. Adicionalmente, si el número de valores permitidos es muy grande, es
probable que algunos de los valores menos comunes no aparezcan en los datos
de entrenamiento en virtud de que estos se obtienen a través de un proceso de
muestreo. En [27], [28], [48] se presentan algunos trabajos sobre este enfoque.
Si se desconocen los valores de salida, existen otras formas de abordar el
problema de la codificación, por ejemplo en [23] se presenta un algoritmo de
agrupamiento aglomerativo basado en similitud para variables mixtas (categóri-
cas y numéricas) propuesto por Goodall en [11] para problemas de taxonomı́a

biológica. La idea central que exponen para definir la medida de similitud entre
dos objetos es otorgar mayores pesos a las coincidencias de valores de carac-
terı́sticas poco comunes; asimismo, no asumen las distribuciones subyacentes de
los valores de las caracterı́sticas. En [1] se presenta un método de agrupamiento
basado en el algoritmo k-means que es capaz de codificar de manera conjunta las
propiedades numéricas y categóricas gracias a una función de costo y medida de
distancia basada en la co-ocurrencia de valores. En [16] se presenta una nueva
función de distancia que toma en cuenta ambos términos, la distancia euclidiana
y una medida de similitud ponderada en atributos categóricos. Similarmente, en
[25], los autores sugieren un enfoque basado en el concepto de acumulación de
evidencia, cuya principal función es combinar en una sola partición los resultados
de múltiples agrupaciones tomando las co-ocurrencias de pares de patrones en el
mismo grupo. Otras alternativas de codificación, como la planteada en [15], pro-
pone un modelo de mapa auto-organizado generalizado basado en el modelo de
Kohonen [21], que ofrece un método para expresar la similitud entre valores no
numéricos a través de jerarquı́as de distancia permitiendo el proceso de valores
categóricos en el entrenamiento. Con esto se unifica el cálculo de distancia de
variables numéricas y no numéricas. En [24] se propone un método que codifica
cada valor categórico con base en su valor informativo en términos de la entropı́a
de Shannon, resultando en un enfoque computacionalmente eficiente.
Las diferentes formas de abordar el problema de codificación inducen una
transformación de los valores cualitativos a un espacio métrico donde las relacio-
nes de similitud entre estos pueden ser expresadas en términos de operaciones
aritméticas y, en consecuencia, es posible describirlos a través de estadı́sticos de
centralidad y dispersión como la media y desviación estándar. Es importante,
antes del análisis y diseño de modelos matemáticos, asegurarnos de que los datos
cualitativos sean codificados a través de alguno de los enfoques señalados.
3. Datos no estructurados
Hasta aquı́ hemos señalado las diferencias entre los datos numéricos y ca-
tegóricos, haciendo énfasis en las tareas de transformación de estos últimos para
hacer posible su análisis cuantitativo. Usualmente, tanto los datos numéricos
como los categóricos representan atributos de entidades u objetos de algún do-
minio que pueden ser organizados bajo las pautas de un modelo de datos [7]. Sin
embargo, existen otros tipos de datos que requieren de una transformación que
habilite su análisis desde el punto de vista cuantitativo. En muchos dominios,
entre ellos el dominio médico, se tienen datos en otros formatos, como texto
o imagen, que requieren ser procesados con el fin de extraer información en la
forma de propiedades cuantitativas o numéricas. Estos datos son tı́picamente
conocidos como no estructurados dado que no están enmarcados bajo ninguna
estructura o modelo. En la Tabla 2 se presentan algunas diferencias puntuales
entre datos estructurados y no estructurados.
Tabla 2: Diferencias entre datos estructurados y no estructurados

Datos estructurados Datos no estructurados
Modelos predefinidos Modelos no predefinidos
Caracterı́sticas Usualmente solo texto Diversos formatos
Fácil de buscar Difı́cil de buscar
Aplicaciones
Base de datos relacionales Bases de datos NoSQL
Ubicación
Data warehouses Data warehouses
Data lakes
Fechas Archivos de texto
Números telefónicos Reportes
Ejemplos Números de seguro social Mesajes de texto
Números de tarjeta de crédito Videos
Direcciones Imágenes
En esta sección se presentan algunas tareas de procesamiento de datos no

estructurados en el contexto clı́nico que permiten extraer propiedades cuantita-
tivas susceptibles de ser analizadas y modeladas a través de técnicas estadı́sticas
y de aprendizaje automático.
3.1. Texto
La información médica en formato textual tiene dos variantes que deben tra-
tarse de manera distinta para su correcto procesamiento. Por un lado, hay que
considerar que uno de los tipos de datos básicos de la mayorı́a de los lenguajes de
programación (y de las bases de datos) es el tipo de dato cadena (string o text en
documentación técnica) que, para efectos de procesamiento, debe ser utilizado
como datos categóricos. Ejemplos de este tipo de información médica los pode-
mos encontrar en los resultados de un análisis clı́nicos para medir el ácido úrico.
La información de este examen podrı́a contener la leyenda “Valores normales”,
indicando que se encontró un rango de 3.5-7.2 (en varón). En este caso, la in-
formación de la leyenda es ciertamente de tipo textual, pero su procesamiento
mediante algoritmos debe hacerse de acuerdo con lo señalado en la Sección 2
Datos Categóricos. Esto es debido a que los datos textuales no corresponden a
una narrativa o una descripción, lo cual nos lleva al segundo caso, que se discute
a continuación.
Las notas médicas, al ser descripciones de información destinadas a ser leı́das,
comprendidas e interpretadas por médicos, deben ser tratadas mediante algo-
ritmos de inteligencia artificial (IA) para extraer conocimiento. En particular,
toda información textual que represente una narrativa puede ser insumo de al-
goritmos de procesamiento de lenguaje natural (PLN). La información textual
proveniente de notas médicas, descripciones, valoraciones, artı́culos cientı́ficos,
reportes técnicos, entre otras, representa una fuente vasta en conocimiento, pe-
ro su correcto aprovechamiento representa también grandes e interesantes retos
tecnológicos que han motivado el estado del arte en el procesamiento de este
tipo de información. En efecto, la IA y el PLN son áreas de investigación que

han mostrado importantes progresos en la generación de modelos y la aplicación
de algoritmos para el procesamiento de información médica. Ası́, se han desa-
rrollado varias lı́neas de investigación en PLN con enorme potencial en el campo
de la medicina, de las cuales hemos seleccionado algunas por ser de interés al
contar con algún desarrollo tecnológico en procesamiento de texto en español de
México.
Reconocimiento de entidades nombradas La primera lı́nea de investiga-

ción que presentaremos se conoce como reconocimiento de entidades nombradas
(NER, por sus siglas en inglés). El NER refiere a la detección y clasificación
automática de entidades nombradas en documentos de dominio especı́fico. Es
decir, un módulo de NER debe procesar bloques de texto para luego producir
un bloque de texto anotado con las entidades detectadas. Un ejemplo básico de
texto anotado serı́a:
<PERSON>Jim</PERSON>, originario de <LOC>Seúl</LOC>,

compró 300 acciones de <ORG>Acmé Corp.</ORG> en <TIME>2006</TIME>.
En el ejemplo anterior han sido detectados y clasificados el nombre de una

persona, un nombre de ciudad, un nombre de compañı́a (dos tokens o unidades
léxicas) y una expresión temporal.
Actualmente, los sistemas de reconocimiento de entidades para el inglés tie-
nen un rendimiento cercano al humano, pero cabe mencionar que, para el es-
pañol, hay cierto rezago debido, en parte, a que hay menos corpus disponibles
y los analizadores léxicos suelen ser menos sofisticados. No obstante, esta par-
ticular lı́nea de investigación del PLN ha cobrado bastante relevancia gracias
al potencial uso, no solo en el ámbito médico, sino prácticamente en cualquier
área de conocimiento: Quı́mica [39], Biologı́a [35], Historia [42], Geologı́a [43],
Geografı́a [31] y por supuesto medicina [45].
Aunado a lo anterior, las técnicas actuales tienen, hoy por hoy, un alto des-
empeño en la detección de entidades de dominio especı́fico, y también contribuye
el hecho de que existe una amplia gama de herramientas de cómputo disponi-
bles en el mercado. Las más exitosas en implementaciones de software utilizan
modelos de máxima entropı́a (MaxEnt), campos aleatorios condicionales (CRFs,
por sus siglas en inglés) y modelos neuronales de aprendizaje profundo (Deep
Learning).
En el marco MaxEnt, la probabilidad de las etiquetas NER para una secuen-
cia de palabras se modela mediante la máxima entropı́a. Para este efecto, se
define un conjunto de funciones de caracterı́sticas arbitrarias que deben ponde-
rarse utilizando un solo parámetro. Las funciones de caracterı́sticas podrı́an con-
siderar aspectos léxicos como recuento de palabras, uso de mayúsculas, prefijos y
sufijos, funciones basadas en diccionario, entre otras caracterı́sticas dependientes

del idioma.4
Un CRF es un modelo estocástico general comúnmente utilizado para etique-
tar y segmentar datos secuenciales; proporciona un marco general para construir
modelos de datos secuenciales. En el NER, una secuencia observada durante la
etapa de entrenamiento es la secuencia de tokens que se ajustan a una oración
o a un documento, y la secuencia de estados corresponden a las etiquetas de
entidad proporcionadas durante esta etapa. Dado que los idiomas difieren de
las convenciones que utilizan para las entidades nombradas, las caracterı́sticas
deben ser especı́ficas para cada idioma. Por lo tanto, una restricción de este
enfoque es que su efectividad es limitada y puede variar de un idioma a otro.5
En el enfoque de aprendizaje profundo se utiliza una red neuronal tanto
para el aprendizaje de caracterı́sticas como para la clasificación de entidades.
Las palabras de una oración se tokenizan y luego se dividen en caracterı́sticas
y se agregan en un vector representativo llamado Word Embedding. Luego, este
vector se alimenta a una red neuronal convolucional que hace una clasificación
basada en el peso asignado a cada caracterı́stica dentro del texto [41]. La etapa
de entrenamiento requiere una gran cantidad de datos etiquetados manualmente
para NER.6
Otro impacto positivo que han tenido los sistemas NER es que la detección de
entidades nombradas se puede conectar con otros procesos, a manera de pipeline,
con el objetivo de realizar tareas más complejas tales como la extracción de
coordenadas a partir de textos o Geoparsing [2], la traducción automática, entre
otras. En este sentido, el reconocimiento de entidades nombradas se convierte
en la piedra angular en varios tipos de procesamiento de información y de ahı́
su relevancia.
Aunque los primeros sistemas de reconocimiento de entidades nombradas es-
taban basados en reglas léxicas [40], los métodos más modernos recaen en los
métodos matemáticos antes mencionados. No obstante, cabe mencionar que los
métodos basados en léxico se desempeñan muy bien en documentos de áreas
de especialidad y, particularmente, en ciencias biológicas. Como muestra de es-
to, consideraremos la Tabla 3, extraı́da de [14]. En la Tabla 3 se replican los
resultados de reconocimiento de entidades nombradas para un sistema médico
usando dos diferentes métodos: el primer método, basado en léxico y expresio-
nes regulares (REGEX) y el segundo método basado en una red neuronal (NN,
por sus siglas en inglés) artificial entrenada con literatura médica. La evaluación
presentada en el texto original se dividió en tres sub-tareas: reconocimiento de
sı́ntomas de una sola palabra (Monomio), reconocimiento de sı́ntomas de dos
4
La biblioteca Apache OpenNLP proporciona un modelo NER basado en MaxEnt.
https://opennlp.apache.org
5
El Stanford CoreNLP ofrece software NER basado en CRF. https://stanfordnlp.
github.io/CoreNLP/
6
El paquete Spacy proporciona un módulo NER basado en CNN. https://spacy.
io/usage/training
palabras (Binomio) y reconocimiento de sı́ntomas de más de dos y hasta siete

palabras (n-grama). Las métricas utilizadas fueron precision y recall. Los resul-
tados mostrados en la Tabla 3 nos revelan aspectos muy interesantes de cara
al procesamiento de textos médicos. Se observa que, aunque el método REGEX
está limitado a detectar únicamente los términos en un lexicon pre-definido, es
muy preciso al ser utilizado en literatura especializada, como es el caso de la
medicina. Sin embargo, su nivel de recall cae rápidamente al aumentar la com-
plejidad de los términos a detectar. El método NN, por el contrario, tiene una
precision ligeramente menor, pero su cobertura es mejor detectando entidades
de mayor complejidad. Esto se debe a que, a diferencia de REGEX, el método
NN no depende de un léxico fijo de términos y esto lo hace robusto en el reco-
nocimiento de patrones que aprende durante la fase de entrenamiento. Incluso,
otra propiedad interesante del método NN es que es capaz de detectar entidades
con errores ortográficos.
Tabla 3: Resultados de reconocimiento de entidades nombradas para un sistema

médico usando dos diferentes métodos.
Precision Recall Precision Recall Precision Recall
Monomio Monomio Binomio Binomio n-gram n-gram
REGEX 1.0000 0.6821 1.0000 0.5748 0.9117 0.4033
NN 0.9120 0.6171 0.9545 0.7608 0.8379 0.5669
Una buena alternativa para extender las bondades del método REGEX en
textos médicos se puede encontrar en el proyecto covidminer7 , el cual utiliza
ontologı́as para detectar conceptos relacionados al COVID-19, sı́ntomas, men-
ciones de muestreos, comorbilidades, a partir de información obtenida de exper-
tos y de Wikidata. El software se usó para analizar notas médicas que fueron
proporcionadas por autoridades médicas durante el transcurso de la pandemia
de COVID-19 y que requerı́an soluciones precisas y rápidas de implementar. A
partir de un primer léxico médico especializado durante el desarrollo de la pan-
demia en México, se establecieron las entidades de interés a encontrar en las
notas médicas. Usando este recurso, se elaboró una ontologı́a ad hoc, en la cual
los términos a encontrar fueron relacionados con nuevos términos y unificados
mediante un identificador único. Por ejemplo, entre el léxico de los sı́ntomas de
interés, el término disnea, de la Figura 1, puede ocurrir de esta manera, pero
también puede ser referido como dificultad respiratoria. Ası́, para poder llevar a
cabo una detección y conteos efectivos de las menciones de este sı́ntoma, existe
un ID 𝑄188008, el cual refiere al sı́ntoma como un concepto, independientemente
de la manera en que es mencionado en los textos, tal y como se muestra en el
siguiente extracto. Usando esta metodologı́a, se puede contar el número de veces
que los pacientes refirieron haber tenido algún sı́ntoma de COVID-19 y contras-
7
El repositorio covidminer proporciona un módulo completo para NER en Español
basado en REGEX y ontologı́as. https://github.com/alemol/covidminer
tar con las menciones en los diagnósticos médicos, pues ambos se relacionan a
través del concepto con un ID como se muestra en la Figura 1.
Figura 1: Ejemplo de detección de sı́ntomas de COVID-19 mediante ontologı́as.

Obtenido con el software covidminer: A Text Mining Emergent Library for Infor-
mation Extraction from Medical Notes in Spanish during COVID-19 pandemic,
disponible en GitHub.
Para finalizar esta sección, mencionaremos que, hoy en dı́a, los métodos de
NER más utilizados están basados en modelos matemáticos. Por su relevancia,
en la sección siguiente nos centraremos en modelos neuronales de aprendizaje
profundo, a partir de los cuales no solamente es posible caracterizar entidades
nombradas en el contexto médico, sino que también son, por sı́ mismos, modelos
del lenguaje que permiten una gran variedad de aplicaciones en el procesamiento
de textos.
Word Embeddings. Los Word Embeddings son representaciones vectoriales

de palabras que se pueden extender a representaciones de documentos. Estos
vectores se generan con el propósito de codificar información textual median-
te espacios métricos construidos para modelar la semántica del lenguaje. Desde
el punto de vista del aprendizaje automático, los Word Embeddings son útiles
porque, a través de vectores densos de números reales, son capaces de repre-
sentar caracterı́sticas de los textos. Esto permite encontrar relaciones mediante
operaciones de álgebra lineal, precisamente con la intención de poder modelar
la semántica del lenguaje natural a través de una abstracción del significado.
Además, desde su origen, los Word Embeddings han sido pensados como un
método de codificación que facilita a ciertos algoritmos a reconocer patrones,
particularmente los algoritmos de las redes neuronales.
Si bien la generación de Word Embeddings tiene fundamentos similares, in-
dependientemente de la implementación, hay diferentes formas de obtenerlos.
Ası́, podemos agrupar las maneras especı́ficas de generar Word Embeddings ob-
servando las tareas que resuelven, ası́ como los retos especı́ficos del dominio para
el que se construyen.
Existe un primer grupo de Word Embeddings pre-entrenados de propósito

general, la gran mayorı́a de estos basados en modelos neuronales. Por citar al-
gunos mencionamos: word2vec [29], Glove [37] y fastText [6]. Una variante más
reciente, también de propósito general, son los llamados Word Embeddings con-
textuales, basados en modelos de aprendizaje profundo Deep Learning [5], entre
los que figuran: ELMo [38] o BERT [9].
Otro grupo corresponde a la construcción de Word Embeddings especı́ficos
para resolver un problema de aprendizaje como la clasificación. Entre estos,
es de interés citar trabajos de investigación en los cuales se han creado Word
Embeddings especı́ficos para el español de México y que han servido en proyectos
como la clasificación automática de solicitudes de atención del servicio de locatel
de la Ciudad de México8 [32] y la clasificación de mensajes con discursos de odio
en redes sociales [30], [8], [3]. En este grupo, es de especial interés también el
trabajo propuesto en [33], donde se procesaron textos de transcripciones médicas
de pacientes con necesidad de realizar una cirugı́a y pacientes que simplemente
iban a una consulta médica regular para luego clasificarlos de manera automática
usando una representación espectral para asociar caracterı́sticas de imágenes
médicas.
Por último, también especı́ficamente en el área medicina, pero exclusivamente
para inglés podemos mencionar el proyecto BioBERT [22], el cual es un modelo
de Word Embeddings contextuales de textos médicos, el cual fue entrenado con
resúmenes provenientes de PubMed y textos completos provenientes de revistas
biomédicas. También, el modelo ClinicalBERT [4], el cual fue entrenado con
notas médicas extraı́das de los datos de MIMIC-III database [17].
3.2. Imágenes
El procesamiento de imágenes con algoritmos de inteligencia artificial tuvo

una gran evolución con la incorporación del aprendizaje profundo. La arquitectu-
ra de red neuronal que lo cambió todo fue, sin duda, la red neuronal convolucional
(CNN, por sus siglas en inglés). Las redes neuronales convolucionales procesan
imágenes con el objetivo de extraer sus caracterı́sticas. Esta red es ampliamente
utilizada en aplicaciones como el reconocimiento de objetos en imágenes [12]. Las
CNNs se componen de dos partes: la parte convolucional y la parte densamente
conectada. La parte convolucional consiste en realizar operaciones teniendo en
cuenta la naturaleza matricial de una imagen.
Una imagen está constituida por pı́xeles, los cuales representan un determi-
nado color a partir de valor un numérico, generalmente entre el rango de 0 a 255.
Cada uno de estos pı́xeles colorea una región de una imagen y, al tener mayor
cantidad de pı́xeles, es posible representar imágenes más complejas. Como se
8
El 0311 Locatel es el sistema de reportes de servicios urbanos y atención de no
emergencia de la Ciudad de México. Una Inteligencia Artificial desarrollada por
un equipo de CentroGeo fue transferida e incorporada al servicio de la CDMX.
https://311locatel.cdmx.gob.mx
Figura 2: Estructura de una imagen.
puede observar en la Figura 2, los pı́xeles A, B, C, D son solo una pequeña parte
de una imagen mucho más grande.
Operaciones convolucionales. Una convolución hace referencia al proceso

de extraer caracterı́sticas de una imagen aplicando un filtro. El filtro recorre la
imagen realizando operaciones sobre pı́xeles contiguos, con el objetivo de extraer
patrones.
Figura 3: Ejemplo de convolución en una matriz de dimensiones 7 × 7.
En la Figura 3 se puede observar cómo se realiza una convolución a una

matriz 7 × 7. En la región resaltada se aplica el filtro, es decir, se va a realizar
el producto punto entre los valores de la región y los valores del filtro. Eso,
como resultado, nos dará un equivalente convolucional de dicho pı́xel, el cual ha
extraı́do caracterı́sticas de los valores adyacentes. Los patrones que se obtienen
dependen del filtro que se haya utilizado. Algunos filtros son capaces de encontrar
caracterı́sticas especiales, como eliminar fondos con el objetivo de solo fijarse en
el objeto enfocado, resaltar las lı́neas verticales de la imagen, resaltar las regiones
con mayor contraste, entre otros. Al aplicar un filtro a la imagen, ciertos rasgos
se pueden resaltar, por ejemplo, el color negro en la imagen original, dando como
resultado una mayor representación del pelaje caracterı́stico del mapache, como
los son sus bigotes y el pelaje que rodea los ojos.
Junto con estas operaciones también se realizan los procesos de Pooling y

de Flattening. El proceso de Pooling consiste en reducir la cantidad de carac-
terı́sticas, con el objetivo de acelerar tiempos de procesamiento y reducir el uso
de memoria. En el caso de Flattening, los algoritmos de aprendizaje automático
reciben como entrada vectores unidimensionales, por lo cual se hace necesario
convertir las imágenes que son bidimensionales a un vector de una sola dimen-
sión.
Figura 4: Ejemplo de la operación de Pooling en una red de convolución.
En la Figura 4 se puede observar cómo funciona el método de pooling en

dos instancias diferentes. En el caso Max Pooling se selecciona una región de la
matriz original y de esa región se obtiene el mayor valor, esta operación se repite
hasta recorrer toda la matriz original. Otra forma de obtener estos valores es a
través de Average Pooling, donde se calcula el promedio de la región seleccionada.
De igual forma, se repite este proceso hasta recorrer toda la matriz original. El
resultado final es generalmente una imagen de dimensiones mucho más pequeñas
que la imagen original, pero que conserva la información necesaria para realizar
operaciones de aprendizaje automático, reduciendo costos computacionales.
Figura 5: Ejemplo de Flattening en una red de convolución.

En la Figura 5 se puede observar cómo funciona el flattening para dos ins-

tancias diferentes. En el caso de aplanamiento sencillo (Flatten) simplemente
se concatena cada fila de la matriz, una detrás de la otra, obteniendo la repre-
sentación de todos los valores de la matriz en un vector unidimensional. Otra
forma de convertir la matriz a un vector es obteniendo el valor promedio de
cada una de sus columnas (Global Average), donde se calcula el promedio de
cada columna, con el objetivo de obtener un vector representativo de la matriz
de tamaño equivalente a su cantidad de columnas. Este proceso se realiza puesto
que los algoritmos de aprendizaje automático utilizan vectores como parámetros
de entrada, por lo cual una imagen debe ser transformada a un vector para que
el algoritmo de aprendizaje pueda procesarla.
Procesamiento de imágenes médicas para apoyo al diagnóstico. En [33]

se detalla un enfoque capaz de extraer las caracterı́sticas de varias modalidades
(tipos de dato) y obtener una representación unificada que pueda ser usada para
obtener un modelo que describa el problema de manera conjunta. Es relevante
mencionar que, para la modalidad de imagen, se usaron imágenes médicas como
caso de estudio, para lo cual se utilizó un conjunto de datos de 1619 instancias de
imágenes colorrectales [19], donde se tienen pruebas visuales de tejido del colon
de pacientes, las cuales son examinadas con el objetivo de encontrar signos de
cáncer colorrectal.
Figura 6: Instancias de imágenes colorrectales.
Como se puede observar en la Figura 6, la primera fila hace referencia a tejido

con señales de tumores, mientras que en la segunda fila se muestra tejido sano.
El modelo de aprendizaje automático presentado clasifica cada imagen con su
correspondiente etiqueta. Para lograrlo, utiliza el modelo Inception, una CNN
para extraer las caracterı́sticas de cada clase y usarlas como un vector represen-
tativo. Luego, el vector representativo es utilizado como una de las modalidades
que permiten a un clasificador determinar signos de cáncer colorrectal.
3.3. Series de tiempo de signos vitales
Los signos vitales son la cuantifación de acciones fisiológicas, como la frecuen-

cia cardiaca (FC), la frecuencia respiratoria (FR), la temperatura corporal (TC),
la presión arterial (PA) y la saturación de oxı́geno en sangre (SpO2), que indican
la calidad del funcionamiento orgánico de una persona. La PA puede analizarse
en su valor sistólico o diastólico, PAs y PAd , respectivamente, ası́ como por su
valor medio (MAP, por sus siglas en inglés). La monitorización continua de los
signos vitales de un paciente es un procedimiento habitual en la práctica clı́nica,
lo cual permite obtener una serie de tiempo por cada signo vital observado. Una
serie de tiempo es un conjunto de muestras obtenidas mediante instrumentos de
monitorización, las cuales se encuentran ordenadas de forma sucesiva. De mane-
ra formal, sea 𝑋 un conjunto de muestras 𝑋𝑡 de un signo vital donde cada una
ocurre de forma aleatoria en un tiempo especı́fico 𝑡.
Las series de tiempo permiten a los profesionales de la salud comprender
la condición que guarda un paciente en términos de su estado fisiológico, per-
mitiendo reconocer episodios adversos asociados al deterioro de su salud. En
la Tabla 4 se muestran episodios adversos para los signos vitales anteriormente
mencionados. En particular, dado que se conocen los valores de referencia con-
siderados como normales para cada signo vital, es posible definir umbrales que
pueden ser un indicio de una posible afectación fisiológica. A fin de ilustrar la
representación y modelado de series de tiempo, a continuación se considera el
caso de episodios agudos hipotensivos (AHE, por sus siglas en inglés), los cuales
son episodios graves que ocurren cuando la MAP decae por debajo de un umbral
no deseado durante un periodo de tiempo.
Representación de series de tiempo de MAP. Desde el punto de vista

médico, la presión sanguı́nea se define como la fuerza que ejerce la sangre contra
las paredes de las arterias y es medida con un esfigmomanómetro. El compor-
tamiento de este signo vital puede verse influenciado por factores como edad,
género, hormonas, medicamentos, fiebre y hemorragias, los cuales pueden afectar
a dicha variable fisiológica. Tomando en cuenta que la actividad del corazón se
compone de distintos momentos, usualmente la medición de la presión sanguı́nea
se realiza considerando sus valores sistólicos y diastólicos. El primer tipo se re-
fiere a la presión dentro de las arterias cuando el corazón se contrae y bombea
sangre a través del cuerpo; en adultos sanos el valor de referencia comúnmente
considerado es 120 mmHg. La presión diastólica es la presión dentro de las arte-
rias cuando el corazón está en descanso (es decir, es la presión entre los latidos
del corazón) y su valor de referencia para adultos sanos es 80 mmHg. Además de
lo anterior, en la práctica clı́nica resulta de mayor valor informativo emplear la
MAP como indicador de posibles eventos adversos en la presión sanguı́nea. En
particular, mediante la medición de la presión arterial sistólica y la diastólica es
posible calcular un valor medio de la presión arterial como MAP = PAs +2*PA 3
d
.
Los valores de MAP superiores a 60 mmHg son considerados como normales pa-
ra mantener los órganos de una persona funcionando correctamente. Por tanto,
valores de MAP inferiores a dicho valor observados durante un periodo apro-
ximados de 30 minutos puede inducir un AHE u otros episodios adversos que

pueden ocasionar daños irreversibles en los órganos del paciente.
Tabla 4: Ejemplos de episodios adversos en series de tiempo de signos vitales.

Notación: lpm (latidos por min), rpm (respiraciones por min), mmHg (milı́metros
de mercurio).
Signo vital Episodio adverso Descripción
FC Taquicardia FC ¿100 lpm
Bradicardia FC ¡60 lpm
TC Fiebre o hipertermia TC ¿38∘
Hipotermia TC ¡35.5∘
FR Bradipnea FR ¡12 rpm
Taquipnea FR ¿20 rpm
Apnea Sin respiración al menos 20 min
PA Hipertensión PAs ¿120 mmHg
PAd ¿80 mmHg
Hipotensión PAs ¡120 mmHg
PAd ¡80 mmHg
SpO2 Desaturación leve SpO2 entre 93-95 %
Desaturación moderada SpO2 entre 88-92 %
Desaturación grave SpO2 ¡88 %
El análisis de series de tiempo presenta desafı́os debido a que las observacio-

nes realizadas al signo vital guardan un orden temporal y natural. Dicho análisis
se puede aplicar al caso de datos continuos de valores reales, datos numéricos dis-
cretos o datos categóricos discretos. A continuación, se describen las propiedades
generales a observar en las series de tiempo de signos vitales.
Tiempo discreto. Las muestras del signo vital son obtenidas en intervalos de
tiempo regulares, expresadas en segundos, minutos, etc.
Orden natural. Representa el orden cronológico de las muestras, el cual debe
preservarse durante el análisis y procesamiento debido a que éste establece
una relación entre las muestras recabadas durante un intervalo determinado.
A manera de ejemplo, en la Figura 7 se ilustra una serie de tiempo de MAP

obtenida de la base de datos MIMIC-II. Esta serie de tiempo representa la evo-
lución de la MAP durante un periodo de 2 horas y 10 minutos, considerando
un muestreo a intervalos regulares de un minuto. En el periodo indicado en la
gráfica en color amarillo, aproximadamente el 90 % de las muestras obtuvo un
valor de MAP≤ 60 mmHg. Por lo tanto, es importante preservar la propiedad
del orden de las muestras durante el procesamiento de las series de tiempo.
En [10] se describe un método de representación que permite abstraer ciertas
caracterı́sticas de interés de las series de tiempo de MAP para el modelado
y predicción de AHEs. La representación empleada se ilustra en la Figura 8,
80
Episodio
Presión arterial media MAP (mmHg)

agudo
●
hipotensivo
●
●
(AHE)
70 ●
●
●●●●
●
● ●
●
● ● ●
●
●
● ●●●●●●●●
● ●
● ● ●●
● ● ●● ●●
● ● ●
●● ●
● ● ●●● ●● ●●
●●●
●
● ● ● ●● ●
● ● ● ●●
● ●● ● ●
●●● ● ●
● ● ●●●
● ● ●●
60 ● ● ●
●
●
●●●
●●
●●
●●●●●●
●●
●●●
Umbral ● ●
●● ●
● ●
●●●●●
●●
●
●●●
episodio ● ●
hipotensivo
50
0
10
20
30
40
50
60
70
80
90
100
110
120
130
Tiempo t (min)
Figura 7: Ejemplo de una serie de tiempo de MAP.
considerando una serie de tiempo de 𝑛 = 90 muestras u observaciones obtenidas

cada minuto. Cada muestra 𝑖 = 1, . . . , 𝑛 sufre una transformación binaria 𝐵𝑖 de
acuerdo con lo siguiente: se asigna un valor de 1 si la muestra de MAP es inferior
o igual al umbral del episodio hipotensivo (es decir, 𝐵𝑖 = 1); o bien se asigna 0
(𝐵𝑖 = 0) en caso de que el valor de MAP se encuentre por encima del umbral
hipotensivo. La gráfica en la parte superior de la Figura 8 corresponde a la serie
de tiempo original, mientras que la gráfica en la parte inferior es el resultado
de haber aplicado la representación descrita. De esta forma es posible obtener
una señal discreta que contiene valores binarios únicamente. La representación
resultante posibilita la obtención de una secuencia de estados asociados a la
presencia/ausencia de un AHE.
4. Conclusiones
Los procesos de atención médica son generadores de datos que registran di-
ferentes escenarios y estados de salud de los pacientes, tı́picamente en la forma
de variables fisiológicas y socio-económicas supeditadas a estructuras tabulares
y relacionales propias de la institución médica que las genera. A partir de estas
variables es posible realizar análisis numéricos y estadı́sticos en aras de encontrar
modelos que apoyen el proceso de toma de decisión. En este escenario, son de
especial atención aquellas variables en las que, por su naturaleza, es imposible
realizar dicho análisis de forma directa y que requieren, por lo tanto, un proce-
so de transformación. En las secciones previas se presentaron algunos enfoques
ampliamente usados para lograr dicha transformación.
Alrededor del proceso de atención también se generan datos en otros forma-
tos provenientes, por ejemplo, de estudios de laboratorio, imagenologı́a, notas
médicas, entre otros. La variedad de formatos y la naturaleza no estructurada
de éstos hacen necesaria la ejecución de tareas de procesamiento que permitan
Presión arterial media (mmHg)
80
●
70 ●
●
●
●
● ● ●
● ●
MAP
● ●
0N
● ● ● ● ●
● ● ● ● ● ● ●
● ●
● ● ● ● ●
● ● ● ●
● ● ● ● ● ● ●
60 Umbral
● ● ● ● ● ● ● ● ●
● ● ●
● ● ● ● ●
● ● ● ● ● ● ● ● ● ● ● ●
● ● ● ● ● ● ● ● ●
●
●
● ● ● ●
● ● ● ●
episodio
50
hipotensivo ●
10
20
30
40
50
60
70
80
90
Tiempo t (min)
Transformación
Tranformaciónbinaria
binaria
1 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
B
BN
0 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
0
10
20
30
40
50
60
70
80
90
Tiempo t (min)
Figura 8: Transformación de serie de tiempo.
extraer propiedades susceptibles de análisis numérico con el fin de diseñar mode-

los que permitan apoyar el proceso de toma de decisiones en diferentes contextos
y problemas de estudio relacionados con la salud de los pacientes. En las seccio-
nes previas se presentaron algunos ejemplos de extracción de caracterı́sticas en
texto, imágenes y series de tiempo que pretenden vislumbrar algunos escenarios
posibles en el procesamiento de datos clı́nicos no estructurados.
Los procesos de transformación presentados están correlacionados con la efec-
tividad de los modelos analı́ticos. Por ejemplo, una exhaustiva y contundente
extracción de caracterı́sticas de imágenes de un órgano blanco guiará el proce-
so de aprendizaje y obtención de modelos de predicción con alta efectividad de
predicción.
Referencias
[1] Amir Ahmad y Lipika Dey. “A k-mean clustering algorithm for mixed
numeric and categorical data”. En: Data & Knowledge Engineering 63.2
(2007), págs. 503-527.
[2] Edwin Aldana-Bobadilla et al. “Adaptive Geoparsing Method for Toponym
Recognition and Resolution in Unstructured Text”. En: Remote Sensing
12.18 (2020), pág. 3041.
[3] Edwin Aldana-Bobadilla et al. “A language model for misogyny detection
in Latin American Spanish driven by multisource feature extraction and
transformers”. En: Applied Sciences 11.21 (2021), pág. 10467.
[4] Emily Alsentzer et al. “Publicly available clinical BERT embeddings”. En:
arXiv preprint arXiv:1904.03323 (2019).
[5] Yoshua Bengio et al. “A Neural Probabilistic Language Model”. En: J.

Mach. Learn. Res. 3 (2003), págs. 1137-1155.
[6] Piotr Bojanowski et al. “Enriching Word Vectors with Subword Informa-
tion”. En: Transactions of the Association for Computational Linguistics
5 (2017), págs. 135-146.
[7] Piter Henry Escobar Callejas y Jorge Lu’s Bilbao Ramirez. Gu’a Meto-
dol—gica para la Investigaci—n Cient’fica: para grado y Posgrado. Lulu.
com.
[8] Thomas Cattin et al. “The Geopolitical Repercussions of US Anti-immigrant
Rhetoric on Mexican Online Speech About Migration: A Transdiscipli-
nary Approach”. En: International Conference on Geospatial Information
Sciences. Springer. 2022, págs. 41-51.
[9] Jacob Devlin et al. “BERT: Pre-training of Deep Bidirectional Transfor-
mers for Language Understanding”. En: Proceedings of the 2019 Conferen-
ce of the North American Chapter of the Association for Computational
Linguistics: Human Language Technologies, Volume 1 (Long and Short Pa-
pers). Minneapolis, Minnesota: Association for Computational Linguistics,
jun. de 2019, págs. 4171-4186.
[10] Jaime Edwin Arciniegas Garcı́a. Método de predicción de episodios hipo-
tensivos basado en una codificación de series de tiempo de presión arterial
media y cadenas de Markov. 2019.
[11] David W Goodall. “A new similarity index based on probability”. En:
Biometrics (1966), págs. 882-907.
[12] Ian Goodfellow, Yoshua Bengio y Aaron Courville. Deep Learning. MIT
Press, 2016. url: http://www.deeplearningbook.org.
[13] Melissa A Hardy. Regression with dummy variables. Vol. 93. Sage, 1993.
[14] Gandhi Hernández-Chan et al. “Medic-Us: Advanced Social Networking
for Intelligent Medical Services and Diagnosis”. En: Current Trends in Se-
mantic Web Technologies: Theory and Practice. Springer, 2019, págs. 213-232.
[15] Chung-Chian Hsu. “Generalizing self-organizing map for categorical data”.
En: IEEE transactions on Neural Networks 17.2 (2006), págs. 294-304.
[16] Zhexue Huang. “Clustering large data sets with mixed numeric and cate-
gorical values”. En: Proceedings of the 1st pacific-asia conference on know-
ledge discovery and data mining,(PAKDD). Citeseer. 1997, págs. 21-34.
[17] Alistair EW Johnson et al. “MIMIC-III, a freely accessible critical care
database”. En: Scientific data 3.1 (2016), págs. 1-9.
[18] Rute Mattos Dourado Esteves Justa et al. “La agresividad tumoral está aso-
ciada a las alteraciones de la integridad celular en las mujeres que sobre-
viven al cáncer de mama: estudio de seguimiento”. En: Nutrición Hospi-
talaria 39.1 (2022), págs. 138-146.
[19] Jakob Nikolas Kather et al. “Multi-class texture analysis in colorectal can-
cer histology”. En: Scientific reports 6 (2016), pág. 27988.
[20] Tı́cia Kocsis et al. “Probiotics have beneficial metabolic effects in pa-
tients with type 2 diabetes mellitus: a meta-analysis of randomized clinical
trials”. En: Scientific reports 10.1 (2020), págs. 1-14.
[21] Teuvo Kohonen. “The self-organizing map”. En: Proceedings of the IEEE
78.9 (1990), págs. 1464-1480.
[22] Jinhyuk Lee et al. “BioBERT: a pre-trained biomedical language represen-
tation model for biomedical text mining”. En: Bioinformatics 36.4 (2020),
págs. 1234-1240.
[23] Cen Li y Gautam Biswas. “Unsupervised learning with mixed numeric and
nominal data”. En: IEEE Transactions on knowledge and data engineering
14.4 (2002), págs. 673-690.
[24] Ivan Lopez-Arevalo et al. “A Memory-Efficient Encoding Method for Pro-
cessing Mixed-Type Data on Machine Learning”. En: Entropy 22.12 (2020).
issn: 1099-4300. doi: 10.3390/e22121391. url: https://www.mdpi.com/
1099-4300/22/12/1391.
[25] Huilan Luo, Fansheng Kong y Yixiao Li. “Clustering mixed data based on
evidence accumulation”. En: International Conference on Advanced Data
Mining and Applications. Springer. 2006, págs. 348-355.
[26] Naresh K Malhotra. Investigación de mercados: un enfoque aplicado. Pear-
son educación, 2004, págs. 65-66.
[27] Richard McElreath. Statistical rethinking: A Bayesian course with exam-
ples in R and Stan. Chapman y Hall/CRC, 2020.
[28] Daniele Micci-Barreca. “A preprocessing scheme for high-cardinality ca-
tegorical attributes in classification and prediction problems”. En: ACM
SIGKDD Explorations Newsletter 3.1 (2001), págs. 27-32.
[29] Tomas Mikolov et al. “Efficient Estimation of Word Representations in
Vector Space”. En: 1st International Conference on Learning Representa-
tions, ICLR 2013, Scottsdale, Arizona, USA, May 2-4, 2013, Workshop
Track Proceedings. Ed. por Yoshua Bengio y Yann LeCun. 2013. url:
http://arxiv.org/abs/1301.3781.
[30] Alejandro Molina-Villegas. “La incidencia de las voces misóginas sobre el
espacio digital en México”. En: Jóvenes, Plataformas Digitales y Lengua-
jes: Diversidad Lingüı́stica, Discursos e Identidades. Página Seis, 2022,
págs. 39-61.
[31] Alejandro Molina-Villegas et al. “Geographic named entity recognition
and disambiguation in Mexican news using word embeddings”. En: Expert
Systems with Applications 176 (2021), pág. 114855.
[32] Alejandro Molina-Villegas et al. “Incorporating Natural Language Proces-
sing models in Mexico City’s 311 Locatel”. En: LatinX in Natural Language
Processing Research Workshop at NAACL 2022. Seattle: North American
Chapter of the Association for Computational Linguistics (NAACL), 2022.
[33] Hernán Guillermo Dulcey Morán. Modelo de aprendizaje multimodal apli-
cado al diagnóstico de padecimientos clı́nicos. 2021.
[34] Mohammad Naghi Namakforoosh. Metodologı́a de la investigación. Edito-
rial Limusa, 2000, pág. 223.
[35] Nhung TH Nguyen, Roselyn S Gabud y Sophia Ananiadou. “COPIOUS:
A gold standard corpus of named entities towards extracting species occu-
rrence from biodiversity literature”. En: Biodiversity data journal 7 (2019).
[36] Charlene Jennifer Ong et al. “Machine learning and natural language pro-
cessing methods to identify ischemic stroke, acuity and location from ra-
diology reports”. En: PloS one 15.6 (2020), e0234908.
[37] Jeffrey Pennington, Richard Socher y Christopher D Manning. “Glove:
Global vectors for word representation”. En: Proceedings of the 2014 con-
ference on empirical methods in natural language processing (EMNLP).
2014, págs. 1532-1543.
[38] Matthew E Peters et al. “Deep contextualized word representations”. En:
arXiv preprint arXiv:1802.05365 (2018).
[39] Tim Rocktäschel, Michael Weidlich y Ulf Leser. “ChemSpot: a hybrid
system for chemical named entity recognition”. En: Bioinformatics 28.12
(2012), págs. 1633-1640.
[40] Satoshi Sekine y Chikashi Nobata. “Definition, Dictionaries and Tagger for
Extended Named Entity Hierarchy.” En: LREC. Lisbon, Portugal. 2004.
[41] Joan Serrà y Alexandros Karatzoglou. “Getting Deep Recommenders Fit:
Bloom Embeddings for Sparse Binary Input/Output Networks”. En: Pro-
ceedings of the Eleventh ACM Conference on Recommender Systems. RecSys
’17. Como, Italy: Association for Computing Machinery, 2017, 279–287.
isbn: 9781450346528.
[42] David A Smith y Gregory Crane. “Disambiguating geographic names in
a historical digital library”. En: Research and Advanced Technology for
Digital Libraries. Springer, 2001, págs. 127-136.
[43] NV Sobhana, Pabitra Mitra y SK Ghosh. “Conditional random field based
named entity recognition in geological text”. En: International Journal of
Computer Applications 1.3 (2010), págs. 143-147.
[44] Ali Hassan Sodhro et al. “An energy-efficient algorithm for wearable elec-
trocardiogram signal processing in ubiquitous healthcare applications”.
En: Sensors 18.3 (2018), pág. 923.
[45] Lorraine Tanabe et al. “GENETAG: a tagged corpus for gene/protein na-
med entity recognition”. En: BMC bioinformatics 6.1 (2005), pág. 1.
[46] Kilian Weinberger et al. “Feature hashing for large scale multitask lear-
ning”. En: Proceedings of the 26th annual international conference on ma-
chine learning. 2009, págs. 1113-1120.
[47] Kyi Pyar Win et al. “Computer-assisted screening for cervical cancer using
digital image processing of pap smear images”. En: Applied Sciences 10.5
(2020), pág. 1800.
[48] Nina Zumel y John Mount. “vtreat: a data. frame Processor for Predictive
Modeling”. En: arXiv preprint arXiv:1611.09477 (2016).











El cuidado de la obra estuvo a
cargo de Montiel & Soriano
Editores S.A. de C. V. El tamaño
del archivo es de 51.7 MB

Libro

Cargado por

Copyright:

Formatos disponibles

Libro

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro

Cargado por

Copyright:

Formatos disponibles

Bigdata en salud: tecnologías emergentes y aplicaciones

José Luis González Compeán

Judith Pérez Marcial

Primera Edición: Noviembre 2022

Montiel & Soriano Editores S.A. de C.V.

Centro de Investigación y Estudios Avanzados del Instituto Politécnico Nacional - CINVESTAV

CINVESTAV Unidad Tamaulipas

Impreso y Hecho en México / Printed and bound in México

Melissa Brigitthe Hinojosa-Cabello[0000−0002−0404−0398] , Miguel

Centro de Investigación y de Estudios Avanzados del Instituto Politécnico Nacional,

Resumen El término Big Data se refiere a la producción de datos a gran

Palabras Clave: Confidencialidad · Control de Acceso · Sobres Digi-

La seguridad informática se refiere a todos aquellos mecanismos y recursos

texto transformado 𝐶𝑇 tras ejecutar 𝑃 −1 , incluso siendo éste un procedimien-

La eficiencia: El cifrado, finalmente, es un requerimiento no funcional que

En este capı́tulo presentamos el concepto, diseño, implementación y evalua-

Datos médicos sensibles SE ABE

Usuarios Búsqueda cifrada

Figura 1: Vista general del concepto de sobres digitales con capacidades de

los cuales son abstracciones fundamentadas en el cifrado de datos no convencio-

1. El productor de datos, que generalmente es un médico, especialista en salud,

3. Tanto el cifrado ABE como parte de la búsqueda cifrada SE-ABE se ejecutan

Nuestra construcción de SDB se realiza sobre emparejamientos bilineales

Dı́a con dı́a, usuarios e instituciones generan y recolectan grandes cantidades

Uno de los métodos más utilizados para asegurar la confidencialidad de los

como parámetro de entrada durante el procedimiento, realizan las transforma-

2.2. Criptografı́a de Clave Privada: Cifradores Simétricos

Figura 2: Flujo de operaciones en el cifrado simétrico.

2.3. Criptografı́a de Clave Pública: Cifradores Asimétricos

Para el cifrado y descifrado, los algoritmos asimétricos utilizan un par de cla-

Figura 3: Flujo de operaciones en el cifrado asimétrico.

ceso de ejecución es más lento. En el ejemplo expuesto en la Figura 3, en un

Los primeros son más eficientes en cuanto al tiempo de procesamiento requeri-

(doctor AND cardiólogo) OR

Figura 4: Flujo de operaciones en el cifrado basado en atributos.

2.4. Cifrado Basado en Atributos

El cifrado basado en atributos (ABE) es una técnica de la criptografı́a de

Como se mencionó anteriormente, la confidencialidad de datos sensibles se

Encapsulamiento de la Llave Desencapsulamiento de la Llave

Cifrado de los Datos Descifrado de los Datos

(a) Criptografı́a de clave pública tradicional.

Cifrado de los Datos Descifrado de los Datos

(b) Cifrado basado en atributos.

Figura 5: Flujo de operaciones en la creación y uso de sobres digitales.

4. Sobres Digitales con Capacidades de Búsqueda

Creación del Índice Seguro

Cifrado de los Datos

(a) Creación del ı́ndice seguro y cifrado.

Creación del Trapdoor

Búsqueda y Recuperación de Datos

Descifrado de los Datos

(b) Creación del trapdoor, búsqueda y descifrado.

Figura 6: Flujo de operaciones en la creación y uso de sobres digitales con capa-

derivar información, saber qué está buscando o el contenido de los resultados

Además, se preservan las capacidades de búsqueda y recuperación de informa-

5. Eficiencia y Seguridad de Sobres Digitales

Crear y abrir SDBs requiere suficiente poder de cómputo. La complejidad

El tamaño de los datos a cifrar, que impacta directamente en la complejidad

El problema de eficiencia en SDBs se aborda a través del uso de patrones

Figura 7: Representación conceptual de un esquema pipeline.