AI Cancer Reporte-Técnico

Sistema de e-salud para el diagnóstico
asistido de cáncer de hueso largo y

pulmones mediante inteligencia
artificial
Entregable 4.1
Proyecto 41756
Responsable técnico:
Dr. José Luis González Compeán
Profesor-Investigador, Cinvestav Tamaulipas
Muyal-Ilal:
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.
Autorizaciones
Fecha: 04/10/2021 Publicación: 04/10/2021 Versión: 1.0
Seguimiento Nombre completo Fecha
Elaboró: Ramón Osvaldo Guardado Medina 04/10/2021
Revisó: Dr. Wilfrido Gómez Flores
Autorizó: Dr. José Luis González Compeán
Control de cambios
Versión Fecha Bitácora
1.0 04/10/2021 Documento Inicial
Reporte Técnico-Proyecto 41756, Entregable 4.1 Página |1

Índice
1. Objetivo del Documento ........................................................................................................................ 5
2. Introducción ............................................................................................................................................ 5
3. Antecedentes .......................................................................................................................................... 6
4. Entregables ............................................................................................................................................ 10
5. Detección de nódulos en pulmón y flujo para la detección asistida para cáncer de huesos largo
10
5.1. Visión artificial .................................................................................................................................. 11
5.2. Preparación de imágenes ............................................................................................................. 13
5.3. Organización de Imágenes ........................................................................................................... 16
5.4. Aumentación de ddatos................................................................................................................ 17
5.5. Etiquetado de Imágenes ............................................................................................................... 18
5.6. Preparación del entorno de programación ................................................................................ 19
5.7. Revision de tensorflow object detection API ................................................................................ 20
5.8. Desarrollo de un modelo de detección de objetos con tensorflow .......................................... 20
5.9. Entrenar el modelo. ........................................................................................................................ 21
5.10. Desarrollo de un modelo de detección de objetos con tensorflow ...................................... 22
5.11. Desarrollo técnico ....................................................................................................................... 25
5.12. Software utilizado ........................................................................................................................ 26
5.13. Descarga de librerías .................................................................................................................. 26
5.14. Extracción de imágenes de archivos DICOM .......................................................................... 26
5.15. Entrenamiento del sistema CADe .............................................................................................. 27
5.16. Generar TF Récords a partir de las imágenes y XML's. ............................................................. 28
5.17. Descargar un modelo pre entrenado. ...................................................................................... 29
5.18. Configurar el pipeline de entrenamiento. ................................................................................ 30
5.19. Entrenar el modelo. ..................................................................................................................... 30

5.20. Exportar el modelo entrenado. .................................................................................................. 31
5.21. Detección. ................................................................................................................................... 31
5.22. Implementación del servicio para la caracterización de procesos asociados al flujo de

trabajo de sistemas de diagnóstico de cáncer de hueso largo asistido ............................................. 32
5.23. Requerimientos ............................................................................................................................ 33
5.24. Alcances ...................................................................................................................................... 33
5.25. Entradas ....................................................................................................................................... 34
5.26. Salidas........................................................................................................................................... 34
5.27. Diseño de la solución y complimiento de normas internacionales ........................................ 34
5.28. Preprocesamiento ....................................................................................................................... 35
5.29. Identificación de flujos de trabajo e información de contenedores ..................................... 35
5.30. Determinar cumplimiento de normas........................................................................................ 38
5.31. Descubrimiento de flujo de trabajo ........................................................................................... 39
6. Transferencia y puesta en producción. .............................................................................................. 40
6.1. Constructor de Sistemas de e-salud y analítica de datos clínicos ............................................. 41
6.2. Esquema de bloques de construcción de flujos de trabajo y servicios de e-Salud basado en

mapas de microservicios y nanoservicios ............................................................................................... 43
6.3. Contenerización de aplicaciones para crear bloques de construcción .................................. 45
6.4. Creación de microservicios y nanoservicios basado en un modelo de rompecabezas......... 46
6.5. Esquema de construcción de cripto-contenedores de datos y cripto-contenedores de

aplicaciones .............................................................................................................................................. 50
6.6. Esquema de despliegue de sistemas de e-salud independientes de la infraestructura ......... 51
6.7. Principios de diseño de un prototipo para el manejo de servicios de e-salud ......................... 53
6.8. Plataforma web para la construcción de sistemas de e-salud .................................................. 56
6.9. Preliminares ...................................................................................................................................... 56
6.10. Interfaz gráfica web .................................................................................................................... 57
6.11. Creación de un servicio de e-salud........................................................................................... 58
6.12. Repositorio de servicios de e-salud creados, compartidos y publicados en la plataforma 64

6.13. Sistema de manejo de catálogo de servicios para que los desarrolladores puedan
acceder a cada producto del servicio .................................................................................................. 67
6.14. Interfaz de programación de aplicaciones y servicios ............................................................ 69
6.15. Servicio de descubrimiento, indexamiento y monitoreo de cripto-contenedores de

sistemas de e-Salud................................................................................................................................... 69
6.16. Etapa 1: Modelado funcional para construir una DfE ............................................................. 71
6.17. Etapa 2: Acceso universal a DST mediante WoT ...................................................................... 73
6.18. Etapa 3: Consume de DST .......................................................................................................... 74
6.19. Prototipo del servicio ................................................................................................................... 74
7. Trazabilidad y verificabilidad de contenidos médicos ...................................................................... 76
7.1. Antecendentes. .............................................................................................................................. 76
7.2. Diseño conceptual y de interacción ............................................................................................ 77
7.3. Servicios de trazabilidad ................................................................................................................ 82
7.4. Componentes de servicio de trazabilidad. .................................................................................. 83
7.5. Red de bloques encadenados ..................................................................................................... 83
7.6. Docker y Docker compose. ........................................................................................................... 85
7.7. Arquitectura. ................................................................................................................................... 85
7.8. Cliente. ............................................................................................................................................. 87
7.9. Generación automática de elementos de interación ............................................................... 91
8. Conclusiones. ......................................................................................................................................... 95
9. Anexos .................................................................................................................................................... 96
9.1. Manual de Usuario .......................................................................................................................... 96
9.2. Manual Técnico ............................................................................................................................ 111
10. Referencias .......................................................................................................................................... 144

1. Objetivo del Documento
El objetivo del presente documento es describir los resultados del desarrollo e

implementación una 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.
2. Introducción
La prevención y seguimiento juegan un rol sumamente importante para abordar

el problema de las enfermedades crónico-degenerativas (ECD) en México. Para esto,
es fundamental que los pacientes tengan un acceso efectivo a servicios de salud que
contemplen el diagnóstico de las ECDs. Sin embargo, las barreras geográficas y
económicas en México imponen retos importantes para acceder a este tipo de
servicios, principalmente para el caso de zonas urbano-marginales y comunidades
rurales. Se ha demostrado que las TICs tienen el potencial para mejorar el acceso a los
servicios de salud por parte de la población. Debido a la escasez de profesionales de
la salud altamente especializados y a la distribución no equitativa de los mismos, en
años recientes se ha incrementado el interés en usar TIC para la prestación de servicios
de medicina a distancia.
Contar con servicios como tele espirometría remota asistida y tele auscultación
con un estetoscopio digital, permitiría a los servicios de salud extender su cobertura y a
los pacientes en comunidades rurales y urbanas marginales evitar traslados costosos y
perder días laborales. Sin embargo, se tiene el problema de que normalmente en esas
regiones las opciones de conectividad de datos son limitadas. Esto podría hacer
inviable u oneroso el despliegue de un sistema de telemedicina tradicional, debido a
que dichos sistemas incluso pueden llegar a requerir anchos de banda dedicados
superiores a 1 Mbps. En lugares donde por cuestiones orográficas no se pueda
establecer un enlace inalámbrico dedicado o no se pueda tender una fibra óptica,
una opción sería contratar enlaces satelitales, sin embargo, el costo de la renta
mensual de los enlaces podría hacer inviable el despliegue de servicios de e-Salud. Por
estas razones es necesario desarrollar sistemas de e-Salud para la detección y
seguimiento de ECDs que se adapten a las opciones de conectividad de datos
disponibles en zonas rurales y urbanas marginales en México, esto con el fin de
proporcionar servicios de salud básicos a sectores de población vulnerables sin realizar

inversiones onerosas para la adquisición de equipos y la habilitación de servicios de
conectividad de datos de banda ancha.
El diseño y despliegue de un sistema de este tipo no es una tarea trivial, debido

a los anchos de banda limitados comúnmente encontrados en varias regiones del país.
Aún más, en el caso de la tele auscultación no se puede simplemente transmitir la
información recolectada con un estetoscopio digital a través de una solución de voz
sobre IP (VoIP). Lo anterior se debe a que los códecs utilizados por VoIP están diseñados
para la transmisión de voz humana comprimida, y podrían modificar la señal de audio
cardio-pulmonar, pudiendo comprometer la calidad del diagnóstico por parte de un
profesional de la salud.
El sistema de e-Salud contemplado dentro del marco del presente proyecto

permitirá que profesionales de la salud altamente especializados (p.ej., neumólogos)
provean asistencia a distancia para: la medición de factores de riesgo para ECDs
como son índice de masa corporal, tensión arterial, glucosa; la realización de
espirometrías; y realicen la tele auscultación a cada paciente. Además, es necesario
tener acceso al historial de las pruebas realizadas en diferentes sesiones. Esto de forma
segura y confiable desde la ubicación geográfica en la que el médico se encuentre,
lo cual se logrará con el repositorio digital de contenidos a desarrollar.
Considerando la existencia enlaces con ancho de banda limitado, la

información obtenida de las Espirometrías y de la auscultación será almacenada en
forma segura en un repositorio digital tolerante a fallas que pueda ser consultado por
especialistas para estudios posteriores. Un repositorio digital de contenidos
anonimizados de espirometría en la nube puede permitir la captura desde diferentes
dispositivos y el acceso ubicuo a especialistas, lo que coadyuvará a mejorar la
eficiencia y seguridad de los flujos de trabajo involucrados en un diagnóstico.
3. Antecedentes
Los sistemas de expediente clínico electrónico (SECE), dispositivos médicos y
plataformas para el manejo de datos de salud mejoran los tiempos de respuesta de la
atención a los pacientes del sector salud de México. Además, estos componentes
posibilitan el fortalecimiento de mecanismos de control de los sistemas de salud y
permiten a las instituciones mantenerse en línea con las diversas políticas, normas
(ejemplos: NOM-024-SSA3-2010 y NOM-004-SSA3-2012) y estándares (ejemplos: DICOM
y HL7). En este contexto, los sistemas de e-Salud se refiere al uso de las diversas

tecnologías de la información, telecomunicaciones y manejo de operaciones para
integrar los componentes antes mencionados un solo sistema coherente y de fácil
manejo cuya operación se base en las normas y protocolos oficiales.
El sistema a-Prevenir© es una plataforma de e-Salud, desarrollada y

debidamente evaluada en nuestro grupo de trabajo para ofrecer servicios de
telemedicina y automonitoreo. En el caso de telemedicina, el sistema está diseñado
para trabajar en enlaces de comunicación con anchos de banda restringidos para
realizar una consulta a distancia con un profesional de la salud (por ejemplo,
enfermeras, nutriólogos o médicos), mientras que en el caso de automonitoreo se
analiza en tiempo cuasi real datos de los usuarios de estos dispositivos médicos (por
ejemplo, signos vitales y somatometría).
El diseño de a-Prevenir© soporta interfaces gráficas de usuario intuitivas, claras,
precisas, orientadas para diferentes tipos de usuarios, con conocimientos mínimos del
uso de las tecnologías de la información. Además, la arquitectura del sistema está
basada en componentes modulares conocidos como bloques tecnológicos, los cuales
permiten una escalabilidad de las funciones del sistema y adaptaciones a
requerimientos específicos. De esta manera, los tiempos de desarrollo de soluciones a
la medida se agilizan al incluir solamente los bloques tecnológicos de interés para los
usuarios potenciales.
Agregando el bloque tecnológico de comunicación al sistema de

automonitoreo descrito anteriormente, el sistema a-Prevenir© puede ser adaptado
para proveer diversos servicios de telemedicina asistidos. De esta manera, después de
obtener los resultados de somatometría, medición de signos vitales básicos y nivel de
glucosa en la sangre (asistido - opcional), se puede brindar al paciente la posibilidad
de realizar una consulta a distancia con un profesional de la salud. La consulta se hace
mediante el módulo de comunicación integrado en esta implementación del sistema
a-Prevenir©. Durante la videoconferencia, tanto el profesional de la salud como el
usuario, pueden consultar el historial de mediciones que se han generado y guardado
previamente en un expediente clínico electrónico. La información recolectada por el
sistema a-Prevenir© es enviada hacia un repositorio de información a través de un
enlace de comunicaciones. Específicamente, puede ser enviada a través de enlaces
de bajo ancho de banda con tecnología ethernet, Satelital o celular.
En este sentido, el manejo de datos sensibles (como lo son las imágenes médicas)
implica la utilización de estructuras de datos que permitan acceder tanto a los datos

como los metadatos, así como sistemas de colocación y localización que permitan
compartir, cargar, descargar, visualizar y/o eliminar datos/metadatos.
El transporte de los datos adquiridos, es uno de los grandes problemas que se

presentan cuando se manejan estos tipos de datos. Lo anterior se debe a que, al ser
datos sensibles, es necesario garantizar servicios de seguridad tales como integridad,
privacidad, confidencialidad y estrictos controles de acceso. De igual manera, al
transportar grandes volúmenes de datos de un sitio a otro, es necesario contar con
distintas técnicas que permitan eficientizar dicho proceso. Para hacer frente a este tipo
de problema se deben utilizar herramientas que permitan realizar operaciones de
cifrado/descifrado para proveer seguridad a los datos, así como operaciones
concurrentes/paralelas para mejorar la utilización de los recursos computacionales.
Esquemas criptográficos experimentales (Sosa et. al, 2017) para compartir, en

forma segura, contenidos en ambientes organizacionales a través de la nube, que
hasta la fecha solo se habían probado conceptualmente y mediante modelos
matemáticos, mostraron la factibilidad de proteger datos sensibles en escenarios reales
en términos de integridad (mediante firmas digitales), confidencialidad y control de
acceso (mediante cifrado por atributos) así como privacidad (mediante el uso de
sobres digitales).
En nuestro grupo de trabajo también se desarrollaron esquemas para el

transporte confiable, seguro, flexible y eficiente de contenidos (ECEI, 2011), los cuales
fueron probados en escenarios reales para que agencias compartan datos espaciales
e imágenes satelitales y posteriormente probados con éxito en el transporte de
imágenes de tomografía. Estas soluciones incluyen mecanismos para reducir el
consumo de almacenamiento producido por procesos de tolerancia a fallos,
mecanismos de paralelismo basados en tuberías de procesamiento que mejoran la
eficiencia en el procesamiento de datos e imágenes, herramientas de transporte de
grandes volúmenes de información a través de flujos de trabajo creados por diferentes
usuarios y agencias, y mecanismos que garantizan la integridad de los datos
transportados extremo a extremo (Sosa et. al, 2017).
En este contexto, las soluciones extremo a extremo permiten a los usuarios

proteger sus datos antes de que estos sean enviados a la nube, así como agregar
confiabilidad a los mismos (mediante cifrado por atributos), y soportar fallas (mediante
técnicas de dispersión de información) que pueden ser provocadas por diversos
problemas, tales como interrupciones de los servicios e incidentes de bloqueo por parte

de los proveedores. Debido a ello, en nuestro grupo se han desarrollado esquemas
basados en emparejamientos criptográficos los cuales conforman un servicio de
almacenamiento de extremo a extremo para modelos de nube híbrida (Sosa et. al,
2020). Estos servicios permiten realizar el intercambio de archivos en escenarios donde
los datos son enviados a la nube, y grupos selectos y autorizados de usuarios pueden
acceder a los mismos.
Por otro lado, para poder crear soluciones de almacenamiento en la nube

extremo a extremo que sean flexibles y eficientes, se diseñó y desarrolló un enfoque de
bloques de construcción (BB) que cuenta con políticas de encadenamiento para la
creación de flujos de trabajo que permiten el transporte de datos desde dispositivos en
la nube (González et. al, 2011). Estas soluciones permiten a los desarrolladores construir
diferentes estructuras como tuberías, pilas y/o grupos de aplicaciones mediante el
encadenamiento de BBs, a través de diferentes interfaces de entrada/salida (memoria,
red, sistema de archivos). Dichas estructuras garantizan, de forma interna, la
confidencialidad y confiabilidad de los datos, así como la autenticación, el uso
compartido y el almacenamiento en la nube privada.
Aunque las soluciones extremo a extremo son factibles para asegurar los datos a
la hora de almacenarlos en la nube, es necesario contar con sistemas que apoyen la
gestión de la información durante el ciclo de vida de los datos clínicos. Para apoyar
dicha gestión, en nuestro grupo de trabajo se desarrolló un modelo de distribución de
productos digitales inspirado en los principios de la cadena de suministros (Vázquez et.
al, 2018). Dicho modelo, permite la gestión de los ciclos de vida de los productos
digitales como cadenas de valor. Así mismo, garantiza la confidencialidad en la
entrega de los datos, evitando no repudio así garantizando la privacidad mediante el
uso de técnicas de cifrado por atributos.
Los escenarios reales donde nuestras propuestas fueron probadas, guardan

similitud con los escenarios de movilidad y flujos de trabajo donde se comparten datos
clínicos realizados por profesionales de la salud al interior/exterior de instituciones y
exhiben marcadas similitudes con los requerimientos de manejo, almacenamiento y
transporte de imágenes médicas (seguridad, confiabilidad, eficiencia y
confidencialidad).

4. Entregables
El documento presenta los siguientes temas en entregables, mismos que se
describen a profundidad cada uno de ellos.
• Detección de nódulos en pulmón y flujo para la detección asistida para cáncer

de huesos largos.
• Transferencia y puesta en producción.
• Verificabilidad de normas nacionales e internacionales
• Trazabilidad y verificabilidad de contenidos médicos
5. Detección de nódulos en pulmón y flujo para la detección

asistida para cáncer de huesos largo
Debido a la alta demanda en especialistas de la salud avocados al diagnóstico de

este tipo de tumores, y que por cada paciente se analizan hasta cientos de imágenes
por estudio, se tiene la necesidad de un sistema de detección de tumores mediante
algoritmos de inteligencia artificial.
El presente proyecto no tiene la intención de sustituir al personal capacitado, sino
proporcionarle una ayuda indicándole las imágenes en las que podría existir algún
tumor, y la región en la que se ubica.
Dado que los tumores presentan diferentes características dependiendo de la parte
del cuerpo en la que se desarrollen, es necesario generar un modelo diferente para
cada uno. Anteriormente, se utilizaron técnicas en las que se buscaban intensidades
de las tomografías que pudiesen indicar, por ejemplo, algún tipo de clasificación en
algunos órganos, pero en el caso particular de cáncer de hueso, estas técnicas no
siempre resultan eficientes, ya que el tumor puede presentar intensidades similares al
de un hueso sano. Es por ello por lo que, para este proyecto, se decidió utilizar nuevas
técnicas de visión artificial que permiten distinguir diferentes patrones más allá de
diferentes intensidades.
Se entrenaron dos modelos de tipo Faster-RCNN, uno para la identificación entrenado
con imágenes de lesiones en hueso, y otro específico para pulmones. Este tipo de
modelos tienen la ventaja de permitir la búsqueda de objetos de cualquier tamaño en
cualquier zona de la imagen, de una forma rápida y eficiente.
Reporte Técnico-Proyecto 41756, Entregable 4.1 P á g i n a | 10

El sistema uso del sistema puede resumirse en etapas, la conversión de imágenes del
formato DICOM a PNG, y la identificación de tumores en imágenes.
5.1. Visión artificial
En inteligencia artificial existen tres tipos de aprendizaje automático:

Supervisado: es útil para entrenar modelos de regresión y clasificación, utiliza datos
históricos etiquetados (para cada muestra se conoce la clase a la que pertenece). El
modelo resultante debe generalizar las características de cada clase, sin memorizar
cada dato.
No supervisado: Se requieren datos históricos, la computadora se encarga de inferir la
relación entre ellos. El modelo aprende por sí mismo, y no requiere de supervisión
alguna, ni de datos etiquetados. El modelo agrupa datos a partir de datos sin etiquetar.
Por refuerzo: No requiere de conocimiento previo para aprender, ni de un humano
para indicarle las acciones que el modelo debe seguir. Aprende de las consecuencias
de sus actos. Está basado en objetivos, donde la experiencia se obtiene al interactuar
con el ambiente. El algoritmo realiza acciones al azar por medio de un simulador, y
recibe incentivos o castigos por cada acción. Después de varias iteraciones, el
algoritmo aprende reglas para realizar una tarea.
Es importante destacar que el tipo de aprendizaje necesario entrenar un modelo
depende de la aplicación que se requiera. Por ejemplo, el aprendizaje no supervisado
en imágenes médicas se suele utilizar para segmentar imágenes en los elementos que
la componen, pero no se identifica cada elemento en la imagen, tiene como ventaja
que no se requiere de un etiquetado manual previo, ya que no se especifica a qué
clase pertenece cada segmento.
Para la aplicación del presente proyecto, en la que no se necesita dividir la imagen de
entrada en segmentos, sino identificar si dentro de ella se encuentran objetos con las
características inherentes a un tumor, es necesario el entrenamiento de un modelo
basado en aprendizaje supervisado. Esto requiere de muestras etiquetadas
manualmente, y el modelo sólo aprende a distinguir tumores similares a los que fueron

utilizados durante el entrenamiento, cualquier lesión, o tumor diferente al esperado,
será descartado. Es esto que por lo que este sistema sirve de ayuda en el análisis de
imágenes, pero no sustituye la experiencia y análisis de los especialistas de la salud. Y
los resultados dependen en gran medida de la calidad de los datos de entrenamiento.
La base de los modelos de identificación de objetos en imágenes actuales se suele
basar en redes neuronales convolucionales, estas tienen como característica que
filtran las imágenes de entrada buscando características pertenecientes a cada clase,
generalmente pasando de características generales a particulares conforme se
avanza en la profundidad del modelo.
Por otro lado, independientemente de la identificación de objetos en imágenes, es

necesario localizar las coordenadas donde se encuentra. En un inicio se definían filtros
de tamaños fijos esperando que fuese similar al del objeto en la imagen, y se realizaba
un barrido con ventanas deslizantes por toda la imagen hasta localizarlo. Aunque los
resultados en algunas ocasiones son buenos, es un proceso demasiado costoso y no
siempre efectivo. Por lo que se han diseñado modelos que minimizan esta búsqueda.
Dividiéndose en dos enfoques principales, utilizar filtros o ventanas de diferentes
tamaños y realizar barridos selectivos sobre toda la imagen; o segmentar la imagen y
aplicar la clasificación a cada segmento redimensionándolos y modificando sus
relaciones de aspecto para igual el de la entrada de la CNN.
El utilizar ventanas de tamaño específico limita los resultados a que el tamaño del
objeto coincida con el esperado, incluso si utilizan ventanas de diferentes tamaños
(usualmente se hace). Aunque tienen la ventaja de que analizan la imagen completa
sin descartar información. Los modelos más conocidos bajo este enfoque son SSD y
YOLO.
Además, segmentar la imagen antes de clasificarla permite tener resultados más
rápidos, y sin la limitante de que el objeto de entrada coincida con el tamaño
esperado, ya que cada segmento puede ser de dimensiones cualquiera (es
redimensionado). Siendo Faster R-CNN el diseño más avanzado en su tipo, donde la
segmentación inicial es automática descartando el segundo plano, y clasificando con
CNN cada segmento encontrado únicamente en el primeo. Este es el tipo de modelo
que se decidió utilizar en esta investigación, ya que los tumores pueden presentarse en
cualquier tamaño, y no se recomienda restringirlo a priori.

5.2. Preparación de imágenes
Las imágenes médicas suelen estar en el formato DICOM (Digital Imaging and
Communications in Medicine). Este formato se compone de dos partes principales:
metadatos y una matriz numérica. Los metadatos contienen información sobre el
paciente y algunos atributos de la imagen, como su tamaño (i.e., número de filas y
columnas). Por otro lado, la matriz representa la imagen medica como tal.
Las imágenes están en el formato DICOM y son en su mayoría tomografías. Una
tomografía se compone de una secuencia de D imágenes. Cada imagen en esta
secuencia se le suele Hamar corte. Para leer una tomografía en una computadora, es
necesario leer las D imágenes de la secuencia en el orden correcto.
Por ejemplo, una tomografía suele estar organizada de la siguiente manera:
volumetric-dicom/
000000.dcm
000001.dcm
…
000098.dcm
en donde volumetric-dicom es un directorio, mientras que 000000.dcm-000098.dcm son

99 archivos en formato DICOM. Cada archivo DICOM en el directorio volumetric-dicom
representa un corte de la tomografía Cada corte se trata de una imagen que está
representada como una matriz de tamaño (H, W), donde H es el número de filas y W
es el número de columnas. Para definir la posición del corte en la secuencia de
imágenes, es necesario acceder al atributo SliceLocation. Una vez que se han leído
todos los archivos DICOM y se ha definido el orden de los cortes, se pueden combinar
todos los cortes en un tensor. Un tensor es la generalización de una matriz en más de
dos dimensiones. También suele emplearse el termino volumen para referirse al tensor.
Para leer un solo archivo DICOM con Python, podemos utilizar las siguientes librerías:
• imageio
• pydicom

La librería imageio2 permite leer todos los archivos DICOM en un directorio y generar el
volumen utilizando la función volread(). El siguiente ejemplo muestra cómo crear un
volumen a partir de las imagenes DICOM del directorio dir_path:
import imageio dir_path =

"/media/data/datasets/volumetric-dicom"
vol = imageio.volread(dir_path, "DICOM")
en donde vol es un tensor compatible con la librería NumPy. También podemos

acceder a las dimensiones del tensor con el atributo shape y al tipo de dato del tensor
con el atributo dtype:
vol.shape # (99, 512, 512)

vol.dtype # dtype('int’)
En este caso, se trata de un tensor de tipo int16. Es decir, cada elemento del tensor es
un entero. Por otro lado, las dimensiones del tensor son (99, 512, 512), es decir, se trata
de una secuencia de 99 cortes de 512x512.Otro de los atributos importantes de una
imagen es el Número de canales. Cuando se genera un volumen con archivos DICOM,
se recomienda incluir el número de canales en el tamaño del volumen. Como
resultado, las dimensiones de un volumen siguen el formato (C, D, H, W) o (Channels,
Depth, Height, Width). En el ejemplo anterior, cada corte es una matriz de 512x512 de
un solo canal (i.e., está en escala de grises). Por lo tanto, las dimensiones del volumen
son (1, 99, 512, 512).
Figura. 5.1: Cortes de una tomografía. Cada imagen representa un corte de la tomografía. Cada
corte es una imagen en escala de grises de 512x512. Cuando se combinan los 99 cortes, se
obtiene un volumen o tensor con las siguientes dimensiones, (1, 99, 512, 512), es decir, una
secuencia de 99 imágenes de 512x512 de un solo canal (escala de grises).

Código 1: Lectura de archivo DICOM con pydicom.
from pydicom import dcmread

from pydicom.pixel_data_handlers.util import apply_modality_lut
import matplotlib.pyplot as plt
import numpy as np
filepath = "/media/data/datasets/volumetric-dicom/000000.dcm" # DICOM file

dicom_image = dcmread(filepath) # read DICOM file
img_t = dicom_image.pixel_array # tensor
img_hu_t = apply_modality_lut(img_t, dicom_image) # tensor in Hounsfield units
print (i mg_t.shape) #(512,512)
print ( img _t.min ()) #0
print ( img _t.max ()) # 4095
print (img_hu_t.shape) #(512,512)
print (img _hu_t.m in()) #-1024.0
print (img _hu_t.max ()) # 3 0 71 . 0
La Figura. 5.1 muestra cinco de los cortes de la tomografía generados a partir del
ejemplo anterior, es decir, con imageio.volread (dir_path, "DICOM"). Cada corte es una
imagen en escala de grises (un solo canal) de 512x512. Cuando se combinan todos los
cortes, se obtiene un volumen o tensor con estas dimensiones, (1, 99, 512, 512).
La librería pydicom es más flexible que imageio, ya que nos brinda mayor control para
leer los cortes y generar el volumen. Por esta razón, emplearemos esta librería de aquí
en adelante. El Código 1 muestra cómo leer un archivo DICOM con pydicom. La
función apply_modality_lut() permite convertir los valores de intensidad a unidades de
Hounsfie ld (HU, Hounsfield Units). De este modo, el rango de valores cambia de [O,
4095] a [-1024, 3071]. La escala de Hounsfield nos permite identificar tejidos y materiales
en una imagen médica. Por ejemplo, el aire se encuentra cerca de -1,000 HU y el agua
cerca de O HU [1]. Como parte del preprocesamiento de las imágenes, algunos
autores (Estevens et. al, 2020), recomiendan limitar el rango a [-1000, 1000]
Lo anterior equivale a la siguiente en PyTorch, donde la variable es un tensor:

ct_a.clip(-1000, 1000, ct_a)
https://pyd icom.github. io/ pydicom/stable /index. Html

https://pydicom.github.io/pydicom/dev/old /workin g_with_pixel_d ata.html
5.3. Organización de Imágenes
Las imágenes suelen organizadas en directorios de la siguiente manera:

dicom/
p1/
p2/
...
p8/
Cada directorio contiene un conjunto de archivos DICOM, generalmente

tomografías. Por ejemplo, el directorio p2 contiene la tomografía CT2 que se
compone de 138 archivos DICOM. Cada archivo DICOM representa un corte distinto.
La tomografía CT2 está organizada de la siguiente manera:
dicom/
p2/
20190228/
CT2/
anonima
2anonima
137anonima
138anonima
en donde dicom, p2, 20190228 y CT2 son directorios, mientras que anónima.
138anonima son 138 archivos en formato DICOM. Los archivos no tienen extensión.
El modelo de clasificación que se pretende usar está basado en Faster_rcnn_resnet50,
un modelo del estado de arte para la localización de objetos en imágenes. Este
modelo considera imágenes con las siguientes dimensiones (3, 512, 512), esto es, una

secuencia de D imágenes de tres canales de 512x512. Algunas de las imágenes
DICOM que no tienen las dimensiones esperadas por el modelo de clasificación.
Es necesario definir el contenido de las imágenes. Muchas de las imágenes son

tomografías computadas, es decir, se componen de una secuencia ordenada de
imágenes o cortes. Sin embargo, algunas de las imágenes parecen ser de otro tipo,
como es el caso de modelos 3D. El modelo de predicci6n de anomalías espera
tomografías computadas en escala de grises, pero en formato RGB de 3 canales.
Definir atributos en metadatos. Los archivos DICOM se componen de una matriz de
valores (i.e., la imagen como tal) y de metadatos (i.e., datos del paciente y datos de
la imagen). Para poder generar la secuencia de cortes de una tomografía, es
necesario que el archivo DICOM contenga el atributo SliceLocation para determinar
la posición del corte en la secuencia. Notamos que algunas imágenes no tienen este
atributo (como cuando se trata de imágenes del modelo 3D).
Además, se suele reducir este rango para resaltar elementos de la imagen. Por
ejemplo, se recomienda usar sólo el rango [0, 3000] para resaltar las masas en
tomografías de los huesos.
5.4. Aumentación de datos
Cuando las muestras son muy pocas, generalmente los resultados del entrenamiento
son pobres, ya sea porque no es capaz de identificar los objetos correctamente, o
porque se genera un sobreajuste y el modelo memoriza las imágenes en lugar de
llegar a un aprendizaje real.
Para minimizar este efecto, es posible generar nuevas imágenes a partir de las
existentes. Debido a que la disponibilidad pública de estudios de este tipo es limitada,
fue necesario aplicar técnicas de aumento de datos, esto es generar imágenes a
partir de las muestras existentes por medio de transformaciones geométricas, y
cambios sutiles en las intensidades de las imágenes. Aunque es posible aplicar otros
cambios como agregar obstrucciones, ruido, y aplicar filtros a las imágenes, se
decidió no aplicarlos para evitar que el modelo memorice estos patrones nuevos que
no estarán presentes en otras imágenes.

Figura 5.2 imagen original se generan nuevas imágenes con ligeras distorsiones .
5.5. Etiquetado de Imágenes
En este paso es necesario definir las regiones de interés en cada imagen. Este paso es
realizado por el médico especialista. Las etiquetas definen las regiones de la imagen
con anomalías y son necesarias para entrenar el modelo y que pueda identificar
dichas regiones.
Como se destacó anteriormente, es importante que las imágenes estén etiquetadas

por un médico especialista. Para continuar con el desarrollo del modelo de detecci6n
de objetos es indispensable contar con las imágenes propiamente etiquetadas, es
decir, generar un archivo XML con Labellmg por cada imagen en donde se
especifique la ubicaci6n y la clase de cada objeto (e.g., bounding box) en la imagen.
Las anotaciones de dichas imágenes con Labellmg Este programa genera un archivo
XML por cada imagen JPG. El archivo XML contiene los metadatos (anotaciones) de la
imagen, es decir, la clase y la ubicación de cada región de interés. La Figura 6.10
muestra una captura de pantalla del programa Labellmg con las anotaciones de la
imagen .png. El archivo generado .xml, contiene la clase y ubicación de la región de
interés en la imagen. En este ejemplo, el nombre de la clase es masa. El contenido de
.xml se muestra en el Código 5.

Código 2: Etiquetas generadas con Labellmg en formato XML. Se resalta el nombre de la imagen y la ubicación de la
región de interés.
<annotation>
<folder>validation</folder>
<filename>26197503341-122.png</filename>
<path>E:\lungriderData\validation\26197503341-122.png</path>
<source>
<database>Unknown</database>
</source>
<size>
<width>512</width>
<height>512</height>
<depth>1</depth>
</size>
<segmented>0</segmented>
<object>
<name>tumor</name>
<pose>Unspecified</pose>
<truncated>0</truncated>
<difficult>0</difficult>
<bndbox>
<xmin>151</xmin>
<ymin>307</ymin>
<xmax>239</xmax>
<ymax>380</ymax>
</bndbox>
</object>
</annotation>
Figura. 5.3 Programa Labellmg. La región de interés de la imagen se encuentra delimitada por un
rectángulo.
5.6. Preparación del entorno de programación
Es necesario preparar el entorno de programaci6n para desarrollar el modelo de

detecci6n de objetos. Utilizaremos el servidor stout de CINVESTAV para entrenar el
modelo. Este mes se conFiguraur6 este servidor con Python 3.7 y Tensor- Flow 2.4. Es
importante destacar que el modelo empleado requiere esas versiones, de otro modo,
no se podrá entrenar ni evaluar.

5.7. Revision de tensorflow object detection API
TensorFlow es una librera de Google para el manejo de tensores y desarrollo de redes

neuronales. Esta librera nos ofrece múltiples herramientas para crear redes neuronales
pro- fundas. Además de esta librera, existe una API especializada en detecci6n de
objetos Hamada TensorFlow Object Detection API (Huan et. al, 2017), disponible en
Github . De acuerdo con el sitio oficial:
“The TensorFlow Object Detection API is an open-source framework built on top of

TensorFlow that makes it easy to construct, train and deploy object detection models.
At Google we've certainly found this codebase to be useful for our computer vision
needs, and we hope that you will as well.”
En este repositorio podemos encontrar diferentes modelos de detección de objetos

reentrenados a partir de un conjunto de entrenamiento llamado COCO (Common
Objects in Context) (Lin et. al, 2015). Este conjunto comprende 91 clases y 328,000
imágenes anotadas. Como resultado, podemos utilizar un modelo pre entrenado para
detectar objectos similares a las clases que se encuentran en el conjunto de
entrenamiento.
En nuestro caso, el tipo de objeto que se desea detectar no se encuentra en el
conjunto de entrenamiento COCO. Aun así, podemos aprovechar las
representaciones aprendidas por un modelo pre entrenado y reutilizarlas para
detectar nuevas clases de objetos. Utilizaremos este enfoque ya que suele ser mucho
más practico que desarrollar un modelo de detecci6n de objetos desde cero.
Detección de objetos de TensorFlow l.x
Nombre Velocidad (ms)

ssd_rnobilenet_vl _coco 30
ssd_rnobilenet_v2_coco 31
ssd_resnet_S0_fpn_coco 76
ssd_in ception_v2_coco 42
ssdli te_rnobil enet_v2_coco 27
faster_rcnn_inc eption_v2_coco 58
faster_rcnn_resnetS0_coco 89
faster_rcnn_r esnetl 0!_coco 106
5.8. Desarrollo de un modelo de detección de objetos con tensorflow

En esta sección se describe el procedimiento general para utilizar la API de detecci6n
de objetos de TensorFlow. Los detalles del procedimiento se pueden consultar en la
documentación.
La Tabla I muestra algunos de los modelos de detecci6n de objetos disponibles en el

API de TensorFlow 2.4. La columna de velocidad se refiere al tiempo de ejecuci6n
considerando una imagen de 600 x 600 y una tarjeta Nvidia GeForce GTX TITAN X.
En general, los pasos a seguir para desarrollar un modelo de detecci6n de objetos son
los siguientes:
• Instalar TensorFlow 2.4.

• Instalar TensorFlow Object Detection APL
• Preparar el conjunto de imágenes y las anotaciones.
• Compilar el conjunto de imágenes y anotaciones en TF Records (un formato
binario).
• Preparar el pipeline de entrenamiento del modelo a partir de un archivo de
configuración.
5.9. Entrenar el modelo.
Exportar el modelo para realizar la detección de objetos. Es importante mencionar que

los pasos 3, 4 y 5 son dependientes del conjunto de imágenes. Es decir, si se desea crear
un modelo que identifique un tipo particular de objeto, es necesario atender dichos
pasos. El resto del procedimiento es independiente del conjunto de imágenes.
Este mes utilizamos un modelo pre entrenado llamado faster _rcnn_resnet50. Se ha
seleccionado este modelo porque permite identificar múltiples objetos de diferentes
clases en una imagen. Esto será de utilidad en imágenes médicas para identificar
objetos de diferentes clases en una imagen. Debido a que las imágenes provistas por
no son suficientes, hemos utilizado un conjunto distinto de imágenes. La finalidad de
esta actividad es preparar el entorno de programaci6n en el servidor stout, validar
todos los componentes necesarios para entrenar el modelo seleccionado y utilizar el
modelo para detectar objetos en imágenes de prueba. Después de haber validado lo
anterior, podremos usar las imágenes anotadas por el médico especialista para
entrenar un nuevo modelo. La Figura. 6.8 muestra la aplicaci6n TensorBoard. Esta
aplicación se ejecuta desde el navegador y permite analizar el progreso del

entrenamiento del modelo. La aplicaci6n se encuentra disponible en el servidor stout
a través de VPN. La Figura 5.4 muestra el estado del servidor stout durante el
entrenamiento del modelo. En la parte superior se observa la carga de trabajo de los
núcleos mientras que en la parte inferior se muestra el registro de eventos del
entrenamiento (iteraciones o steps y el costo o loss).
Figura. 5.4: TensorBoard. Esta aplicación permite revisar el progreso del entrenamiento del modelo.
Figura. 5.5 : Estado del servidor stout durante el entrenamiento del modelo.
5.10. Desarrollo de un modelo de detección de objetos con tensorflow

La API de detección de objetos de TensorFlow 2 ofrece varios modelos pre entrenados
para detección de objetos en el llamado Model Zoo. Seleccionamos algunos modelos
pre-entrenados en imágenes de tamaño 512x512, el mismo tamaño de las tomografías
facilitadas. Evaluamos los siguientes tres modelos de detección de objetos en el
servidor stout (stout.tamps.cinvestav.mx):
• EfficientDet DO 512x512
• EfficientDet D4 512x512
• CenterNet HourGlass 104 512x512
El primer modelo no se pudo entrenar debido a un error: luego de las primeras 500
iteraciones, el valor de la función de costo (loss) es NaN. Como resultado, no es posible
entrenar el modelo ya que no se puede medir el error de predicción. El segundo
modelo tampoco se pudo entrenar debido a que es computacionalmente muy
costoso. El servidor stout cuenta con 40 cores y 32 GB de RAM. Aun así, no fue posible
entrenar el segundo modelo. El último modelo se pudo entrenar. Para entrenar el
modelo de detecci6n de objetos, se realizaron los siguientes pasos, como se describe
en la documentación:
Figura. 5.6 Muestra del conjunto de imágenes de entrenamiento.

Figura. 5.7 Detecci6n de objetos. El modelo detecta los objetos en las imágenes de prueba. En color
verde se muestran las predicciones del modelo.
Preparar las imágenes: Las imágenes se convirtieron de formato DICOM a JPG.

Enseguida, se etiquetaron con Labellmg. Dividimos las imágenes en un conjunto de
entrenamiento (80%) y un conjunto de prueba (20%).
• Generar TF Records. Las imágenes JPG y anotaciones XML son convertidas a un

formato binario.
• Descargar un modelo pre entrenado: se descarga el modelo CenterNet
HourGlass 104 512x512.
• ConFigurar el pipeline de entrenamiento: en este paso se especifica el número
de iteraciones, el número de imágenes por cada batch, la ubicación de las
imágenes de entrenamiento y de prueba, entre otros parámetros.
• Entrenar el modelo.
• Exportar y probar el modelo.
El proyecto está organizado de manera que se puedan evaluar otros modelos de

detección de objetos.
• La Figura 5.6 muestra algunas de las imágenes del conjunto de entrenamiento.

Las regiones de interés se destacan en color rojo.
• La Figura 5.7 muestra las predicciones realizadas por el modelo CenterNet
HourGlass luego de 110, 000 iteraciones. Las anotaciones de referencia se
muestran en color rojo y las predicciones en color verde. El modelo es capaz de
detectar las regiones de interés correctamente. Sin embargo, es importante
mencionar lo siguiente:

• Se requiere una mayor cantidad de imágenes para mejorar la generalización del
modelo. En caso contrario, el modelo puede estar sobre ajustado a los datos
(over.fit).
• Las imágenes que utilizamos para entrenar el modelo no cuentan con una clase,
solo conocemos la ubicación. La Figura 6.1 muestra una imagen con una sola
región de interés. Sin embargo, no conocemos si el objeto dentro del bounding
box es una lesión, es una masa, un nódulo u otro tipo de objeto. Como resultado,
todos los objetos han sido etiquetados como tumor.
5.11. Desarrollo técnico
Para la detección asistida para el cáncer de huesos largos y pulmones existe, un flujo
formal de se lleva a cabo en el presente proyecto, desde la obtención de las imágenes
DICOM, en donde el proceso de extracción de las mismas contiene un formato
adecuado para llevarlo a un sistema en donde se realiza una partición de las mismas
de manera aleatoria y formar un conjunto de entrenamiento y prueba que
regularmente se toman el 80% y 20% de la cantidad total de imágenes. Mismas que se
genera un TF Records a partir de imágenes y XML´s. Continuando con el flujo, se realiza
un pipeline de entrenamiento extrayendo las imágenes y entrenando el modelo,
seguido de la exportación del modelo y prueba del del mismo para obtener el conjunto
de pruebas para la detección asistida para cáncer de huesos largos y pulmones. con
base en marcos de referencia de normas internacionales (NIST, ISO 27001:2013 y COBIT
5) y nacionales (NOM-024-SSA3-2010). El programa, además, descubre el flujo de
trabajo asociado a los archivos de configuración.
El flujo desarrollado recibe de entrada los archivos de configuración y determina que

normas nacionales e internacionales cumple el servicio. El cumplimiento es mostrado
en forma de reporte en donde se observa el porcentaje de cumplimiento del servicio
según la norma correspondiente. El programa además realiza el descubrimiento del
flujo de trabajo asociado a los archivos de configuración. Las normas internacionales y
nacionales son representadas mediante checklists. Cada checklist, contiene los
requerimientos de la norma correspondiente. Los requerimientos pueden ser
garantizados por el servicio creado (de forma sistemática) o mediante intervención del
usuario final (de forma asistida).

Para llevar a cabo el desarrollo de sistema CADe, es necesario descargar los
archivos DICOM de los cuales se obtendrán las imágenes. A continuaci6n se muestran
los pasos para descargar estos archivos.
• Una vez creado el usuario se debe notificar al administrador del servidor para
que otorgue los permisos correspondientes.
• El administrador notificara al usuario que tiene permiso para descargar los
archivos.
• Conectarse mediante VPN para descargar el cliente, el cual realizara la
descarga de los archivos DICOM de manera automática.
5.12. Software utilizado
Para este proyecto se utilizó Anaconda Individual Edition con Python 3.7.6 (default,
Jan 8 2020, 20:23:39) para el desarrollo de los algoritmos. Adicionalmente, se utilizó
LabelImg para realizar el etiquetado correspondiente para las imágenes, el cual
genera un documento XML con la localización del objeto y la clase a la que pertenece.
LabelImg se puede descargar del siguiente enlace: http://tzutalin.github.io/labelimg/.
5.13. Descarga de librerías
El documento requirements.txt contiene el listado de las librerías necesarias para

poder ejecutar los códigos de Python y Jupyter Notebook, por lo que en Anaconda
(prompt) se debe escribir el siguiente código: pip install -r requirements.txt. Uno de los
paquetes instalados es la API de Detecci6n de Objetos de TensroFlow 2, la cual nos
permitirá realizar el entrenamiento de los modelos.
5.14. Extracción de imágenes de archivos DICOM
Una vez que se han descargado los archivos DICOM en nuestro equipo, se extrae la
información correspondiente a la imagen. Para esto, utilizaremos el código
dicom2rgb.py, el cual revisa todos los archivos que contenga la ruta de la carpeta y
las convierte en imágenes con formato PNG. Sin embargo, estas imágenes PNG se
guardan con una capa adicional, esto es el canal de transparencia, por lo que es una
imagen de 4 canales. El código dicom2rgb.py permitirá además hacer la conversión
de RGBA a RGB internamente, dejando las imágenes de 3 canales. En la Figura. 5. 1 se

muestra que ambos códigos cuentan con la variable dcm_dir, la cual debe contener
la ruta de la carpeta donde se encuentran los archivos.
 $ python dicom2rgb.py Ruta_de_entrada Ruta_de_salida
Carpeta/Archivo Descripción
Data/: Imágenes de entrenamiento y prueba para el

entrenamiento. Y archivo label_map.pbtxt, incluye el
nombre y número de clases.
Exported_models/: Modelos entrenados para este proyecto. Y archivo
pipeline.config, se usa para definir el entrenamiento de
cada modelo.
Models/: Archivos necesarios para la ejecución del proyecto. Nota:
El archivo models/research/protoc depende del sistema
operativo.
dicom2rgb.py: Conversión de imágenes dicom a png en rgb.
main.py: Ejecuta los modelos entrenados para detectar tumores en

las imágenes de entrada.
requirements.txt: Contiene la lista de bibliotecas en las versiones necesarias
para la ejecución del proyecto.
5.15. Entrenamiento del sistema CADe
La Figura 5.8 muestra cómo se organizarán los documentos, tanto carpetas como
archivos de python, involucrados en el proyecto, Una vez que se tienen las imágenes
médicas en formato PNG, se realiza la partici6n de las imágenes de manera aleatoria
para generar los conjuntos en train, test y prueba, generalmente es el 70 %, 20 % y 10
%, respectivamente. Al terminar la partici6n de las imágenes, cada partici6n debe
colocar se en su carpeta correspondientes.

Figura 5.8 Organización de documento
5.16. Generar TF Récords a partir de las imágenes y XML's.
Los modelos pre entrenados utilizan archivos record para entrenar en lugar de utilizar
las imágenes en formato PNG, JPG, BMP, etc. Para generar estos archivos, se requiere
de las imágenes y los archivos XML's creados anteriormente como resultado del
etiquetado manual por un especialista de la salud.
Lo primero será abrir una terminal de Anaconda en la carpeta data y ejecutar el

siguiente código python gen_csv.py, directorio_imagenes, nombre_archivo.csv.
Después, se genera el archivo pbtxt con las etiquetas de clase con el siguiente código:
python gen_pbtxt.py csvtrain.csv labels.pbtxt. Por último, se genera el archivo record
a partir de los archivos labels.pbtxt y train.csv. La Figura. 4 muestra un ejemplo en el que
se genera un archivo record.
Figura 5.9 Generaci6n del archivo TF Record de las imágenes de entrenamiento.
Nota: Este procedimiento se realiza para las imágenes de entrenamiento y prueba.

5.17. Descargar un modelo pre entrenado.
En este paso, podemos utilizar distintos modelos pre entrenados con el dataset
COCO 2017 y mediante transfer learning, entrenar nuestro modelo para detectar
anormalidades en imágenes médicas. En la siguiente liga:
https://github.com/tensorflow/models/blob/master/research/object_detection/g3
doc/tf2_detection_zoo.md
Podemos encontrar el listado de los modelos compatibles con la API de Detección

de Objetos de TensorFlow 2. La Figura. 5.10 muestra algunos de los modelos pre
entrenados compatibles y listos para usar con la APL Solo es necesario hacer clic
en el nombre del modelo que se quiere descargar y automáticamente comenzara
la descarga.
Una vez descargado el modelo, se debe descomprimir el archivo en la carpeta de
pre_trained_models. La Figura. 5.11 muestra el directorio con los modelos pre
entrenados que se descargaron.
Figura 5.10 Modelos pre entrenados Model Zoo.

Figura 5.11 Directorio de modelos pre entrenado
5.18. Configurar el pipeline de entrenamiento.
Del modelo descargado anteriormente, ocuparemos el archivo pipeline.config, el

cual contiene toda la configuración del modelo y sólo requiere de unos ajustes:
• num_classes: 1
• fine_tune_checkpoin_type: "detection "
• label_map _path: "directorio_archivo.pbtxt"
• tf_recordjnput_reader { inpuLpath: "directorio _archivo.record"}
• batch_s ize: 1;
Nota: La ruta directorio_archivo.record depender a si se trata de! conjunto de train

o test.
5.19. Entrenar el modelo.
Para realizar el entrenamiento debemos colocar en una nueva carpeta con el

nombre del modelo con el que lo identificaremos dentro de la ruta models. Después se
necesitaremos abrir una terminal Anaconda en la ruta de la carpeta workspace para
escribir el siguiente código:
python model_main _tf2.py --pipeline_configura_path = ruta/models/nornbre_modelo/pipeline. configura --

model_dir=ruta/models/ nornbre_modelo --checkpoint_every_n =200 --nurn_wo rkers=4.

La Figura 5.12 muestra la terminal con los mensajes que se muestran al iniciar el
entrenamiento. En la parte inferior se puede observar que al iniciar muestra el error de
detecci6n durante el entrenamiento.
Figura. 5.12 Terminal con el entrenamiento del modelo en proceso
5.20. Exportar el modelo entrenado.
Una vez entrenado el modelo es necesario exportarlo para poder utilizarlo para la
detección de anormalidades en imágenes médicas. Para eso, pegamos el siguiente
código en la terminal:
Python exporter_train_v2.py –pipeline_conFigura_path = ruta/models/nombre_modelo/pipeline.conFigura --

trained_checkpoint_dir=ruta/models/nombre_modelo/ -- output_director -- imput_type = image_tensor
5.21. Detección.
Para el modelo de lesiones en pulmones, se decidió utilizar la base de imágenes Base

de imágenes: Zhao, Binsheng, Schwartz, Lawrence H, & Kris, Mark G. (2015). Data From
RIDER_Lung CT. The Cancer Imaging Archive. DOI: 10.7937/K9/TCIA.2015.U1X8A5NR,
debido a que cuenta con las imágenes ya etiquetadas, y está disponible
públicamente.
Cada imagen es entonces analizada en búsqueda de tumores, ambos modelos tienen
un funcionamiento similar, sólo se modifica el tipo de entrada esperado, ya sea
imágenes de huesos, o pulmones. Y puede ser ejecutado de la siguiente forma:
 $ python detectorHuesos.py Ruta_de_entrada Ruta_de_salida
 $ python detectorPulmones.py Ruta_de_entrada Ruta_de_salida

Figura 5.13 El modelo entrenado es capaz de identificar tumores en pulmones.
El flujo de trabajo permite la integración de nuevos modelos, ya sea para

mejorar los resultados actuales, o para identificar otros tipos de tumores en imágenes
a partir de un nuevo entrenamiento.
5.22. Implementación del servicio para la caracterización de procesos

asociados al flujo de trabajo de sistemas de diagnóstico de cáncer
de hueso largo asistido
Desarrollar un programa que a partir de unos archivos de configuración .cfg, .json y

.yml, generados por un creador de servicios, determine el grado de cumplimiento de
los flujos de trabajo asociados al archivo de configuración, con base en marcos de
referencia de normas internacionales (NIST, ISO 27001:2013 y COBIT 5) y nacionales

(NOM-024-SSA3-2010). El programa, además, descubre el flujo de trabajo asociado a
los archivos de configuración.
5.23. Requerimientos
Funcionales
• Dados los archivos de configuración .cfg, .json y .yml, el programa

preprocesa los datos para leer y manipular los archivos desde el código.
• El programa identifica la información de los contenedores y los flujos de
trabajo que forman el servicio.
• El programa consulta algunas fuentes de información APIs para obtener
datos y características contextuales de los contenedores. Estos datos
contextuales representan las tareas que ejecuta el contenedor.
• Con base en la información contextual obtenida en el punto anterior, el
programa busca palabras clave para determinar el cumplimiento o no
cumplimiento de las normas internacionales y nacionales.
• Para cada norma, el programa computa el porcentaje de cumplimiento
y genera un reporte donde se visualizan estos resultados.
• El programa descubre el flujo de trabajo asociado a los archivos de
configuración y genera una representación gráfica en un grafo acíclico
dirigido.
No funcionales
• La norma nacional que debe ser verificada es: NOM-024-SSA3-2010.

• Las normas internacionales que deben ser verificadas son: NIST, ISO 27001:2013
y COBIT 5.
• El programa debe ser eficiente.
• El programa debe ser eficaz.
5.24. Alcances
Los archivos de configuración .cfg, .json y .yml representan un servicio que será
desplegado. El programa desarrollado recibe de entrada los archivos de
configuración y determina que normas nacionales e internacionales cumple el
servicio. El cumplimiento es mostrado en forma de reporte en donde se observa el

porcentaje de cumplimiento del servicio según la norma correspondiente. El
programa además realiza el descubrimiento del flujo de trabajo asociado a los
archivos de configuración.
Las normas internacionales y nacionales son representadas mediante checklists.
Cada checklist, contiene los requerimientos de la norma correspondiente. Los
requerimientos pueden ser garantizados por el servicio creado (de forma sistemática)
o mediante intervención del usuario final (de forma asistida).
5.25. Entradas
Los datos de entradas son los archivos de configuración generados por la

herramienta para la creación de servicios y los checklists de las normas
internacionales y nacionales:
• .cfg : Representa la configuración generada por el modelo. En este archivo,

se definen los bloques de construcción (BB), patrones (PATTERN),
requerimientos no funcionales (NRF), etapas de procesamiento (STAGE) y
flujos de trabajo (WORKFLOW).
• stages.json: Este archivo contiene la declaración de las etapas en el
flujo, los directorios de entrada y salida de la etapa y datos de identificación
de los contenedores utilizados.
• docker-compose.yml : Contiene la declaración de los contenedores que se
despliegan con compose o swarm.
• normas nacionales e internacionales: son capturadas en un diccionario de
datos (explicado más adelante) con una estructura bien definida.
5.26. Salidas
Las salidas del programa son un reporte para cada norma en donde se visualiza el
porcentaje de cumplimiento de la norma y la representación gráfica del flujo de
trabajo en un grafo acíclico dirigido.
5.27. Diseño de la solución y complimiento de normas internacionales
La Figura 5.14 muestra el diseño preliminar de solución. Como se puede observar,

el programa está formado por los siguientes procesos: preprocesamiento,

identificación de flujos de trabajo, identificación de información de contenedores,
determinación del cumplimiento, obtención de información contextual de
contenedores, registro de checklists en contratos inteligentes y reportes. La Figura
5.15 muestra el disenso preliminar de la implementación de la solución
Figura 5.14: Diagrama preliminar de solución.
5.28. Preprocesamiento
Este módulo, realiza la lectura de los archivos de configuración .cfg, .json y .yml.
Para identificar los flujos de trabajo, se implementó un módulo que reconoce los
bloques de construcción,
pyyaml. pyyaml permite decodificar el contenido del archivo.yml.
5.29. Identificación de flujos de trabajo e información de contenedores
Para identificar los flujos, bloques de construcción, patrones, requerimientos no

funcionales y etapas de procesamiento, se utiliza el diccionario de datos generado
a partir del archivo .cfg en el pre procesamiento de datos.

Algoritmo 1 Identificación de componentes en archivo .cfg
Require: cfg file path

Ensure: cfg cfg ← {}
file ← read file(cfg file path) current blockdata ← {}
current blockname ← new String
for line in file do
if line == END BLOCK TAG then
if current blockname not in cfg then
cfg[current blockname] ← []
end if
cfg[current blockname].append(current blockdata) current blockdata ← {}
current blockname ← new String
else
attribute ← regex.findAttribute(line)
if attribute then
attribute value ← split(attribute)
current blockdata[attribute value[0]] ← attribute value[1]
else
blockname ← regex.findBlockName(line)
if blockname then
current blockname ← blockname[0]
end if
end if
end if
end for
Figure 5.15: Diagrama de implementación.

La clave “BB” del diccionario contiene la información de todos los bloques de
construcción definidos en el sistema. Cada bloque de construcción representa un
servicio y contiene la siguiente información: “name”, nombre del bloque de
construcción; “command”, el comando que ejecut el bloque de construcción;
“image”, imagen del contenedor. La clave “PATTERN” del diccionario contiene la
información de los patrones. Cada patrón contiene la siguiente información: “name”,
nombre de patrón; “task”, el bloque de construcción que utiliza el patrón; “pattern”, el
patrón que ejecuta. En este caso, pueden existir más claves en función del patrón
utilizado. La clave “STAGE” del diccionario contiene la información de todas las etapas
que forman el flujo de trabajo. Cada etapa contiene la siguiente información: “name”,
nombre de la etapa; “source”, la fuente de datos de entrada a la etapa; “sink”, el
destino de los datos de salida de la etapa; “transformation”, nombre del patrón que
ejecuta la etapa.
La clave “WORKFLOW del diccionario contiene toda la información de los flujos

de trabajo. El número de flujos de trabajo puede ser determinado obteniendo la
longitud del objeto asociado a dicha clave. Un número de flujos de trabajo mayor a 1
indica que se trata de un proceso interinstitucional (*VERIFICAR*). Por otro lado, un solo
flujo de trabajo indica que se trata de un proceso intrainstitucional. Cada flujo de
trabajo contiene la siguiente información: “name”, nombre del flujo de trabajo;
“stages”, etapas qu realiza el flujo de trabajo; “catalogs”, los catálogos utilizados por el
fluj de trabajo (sistema de distribución de contenido). La clave “NRF” del diccionario
contiene la información de todos los requerimientos no funcionales definidos en el
sistema. Cada requerimiento no funcional contiene al menos la siguiente información:
“application”; “type”, tipo de requerimiento, por ejemplo, security. Las claves de cada
requerimiento no funcional pueden variar en función del tipo.
La declaración de los contenedores es especificada en el archivo de

configuración. yml. Sin embargo, la información de identificación de los mismos como
id y nombre es especificada en el archivo de configuración. json. Para obtener esta
información, se utiliza el objeto decodificado por la biblioteca json en el
preprocesamiento de datos. El objeto JSON decodificado contiene la siguiente
información: “workflow name”, nombre del flujo de trabajo; “stages”, contiene la
información de cada etapa, es decir, nombre, fuente de datos de entrada, destino de
datos de salida, identificador y nombre del contenedor que utiliza la etapa;
“containers”, contiene la información de identificación de los contenedores utilizados:
“name”, nombre del contenedor; “id”, hash del contenedor.

5.30. Determinar cumplimiento de normas
Las normas nacionales e internacionales fueron capturadas de forma manual en
checklists directamente en el código utilizando una estructura de datos tipo
diccionario. Cada diccionario representa un checklist de una norma. La estructura de
un diccionario de un checklist es la siguiente:
{
"name": nombre de la norma,
"requirements": [
{
"category": "categor´ıa", "description":
"descripción", "keywords": [ "" , "" , ... ],
"assisted": boolean, "compliance": boolean
}
...
]
}
Para determinar el cumplimiento de las normas internacionales y nacionales, se
utilizan algunas APIs para consultar información contextual de los contenedores que
despliegan el servicio. Estas APIs representan fuentes de información en las cuales se
basará el programa para determinar o no el cumplimiento de las normas. Entre las
fuentes de datos están: API de contenedores, API pub/sub, API Blockchain.
En la estructura del diccionario anterior que representa un checklist, la clave

“keywords” se refiere a las palabras clave que se buscarán en la información
contextual de los contenedores para tener un indicio de que se está cumpliendo o no
dicho requerimiento. Por ejemplo si se el requerimiento trata sobre integridad de datos,
algunas palabras claves podría ser “SHA”, “MD5”, “HASH”, etc. Entonces, el programa
busca estas palabras clave en la información contextual de los contenedores, y si
se encuentra alguna, se determina que el requerimiento es cumplido por el

sistema. La clave “assisted” del checklist indica si el requerimiento necesita asistencia
manual, es decir, si dicho requerimiento no puede ser realizado de forma automática
por el sistema. Lo requerimientos asistido no son verificados. La clave “compliance”
del checklist indica si se cumple (TRUE) con dicho requerimiento o no (FALSE). Como se
puede notar, la clave “keywords” es un dato crítico debido a que en función de este
se determinará si se cumple con dicho requerimiento o no. El Algoritmo 2, muestra el
proceso de verificación de cumplimiento de un checklist.

Algorithm 2 Verificación de cumplimiento de checklist
Require: cfg, checklist, ids containers, SOURCES: APIs endpoints or local file resources.
Ensure: checklist, checks, compliancePercentage, num assisted requirements checks ← 0
num requirements ← 0
num assisted requirements ← 0
context ← new String
for source in SOURCES do
if source is external then
context.append(external.api call resolver(source, ids containers))
else t> source is localfile (cfg, yml or json)
context.append(cfg.find(source))
end if
end for
for requirement in checklist[“requirements”] do
num requirements ← num requirements + 1
if requirement[“assisted”] then
num assisted requirements ← num assisted requirements + 1
continue
end if
if any of requirement[“keywords”] is in context then
requirement[“compliance”] ← true
checks ← checks + 1
end if
end for
return checklist, checks, checks/num requirements, num assisted requirements
5.31. Descubrimiento de flujo de trabajo
Para el descubrimiento del flujo de trabajo, el programa se basa en la

información obtenida por el preprocesamiento de datos del archivo .cfg. El programa
utiliza la información contenida en la clave “STAGE” del diccionario de datos del
archivo .cfg. Una etapa i representa un nodo en el grafo acíclico dirigido. La(s)
entrada(s) (sources) de la etapa i representan los nodos incidentes en esta y la(s)
salida(s) (sinks) representan los nodos salientes de la misma. Basándonos en esta lógica,
se construye el grafo acíclico dirigido que representa el flujo de trabajo utilizando la
biblioteca de python NetworkX 1. El Algoritmo 3, muestra el pseudocódigo del
descubrimiento del flujo de trabajo asociado a un archivo .cfg.
Es posible también dar de entrada un flujo de trabajo, además de los archivos

de configuración. Este flujo de trabajo sería el predeterminado. El formato del flujo de

trabajo predeterminado debe ser un grafo acíclico dirigido especificado con la
biblioteca NetworkX. Si se recibe de entrada el flujo de trabajo predeterminado,
también se realiza el descubrimiento del flujo de trabajo de los archivos de
configuración. En este caso, el programa determina la diferencia entre ambos flujos
de trabajo (Ver Algoritmo 3).
Algorithm 3 Descubrimiento de flujo de trabajo a partir de archivo .cfg
Require: cfg, workflow (optional)

Ensure: discovered wf
discovered wf ← Graph()
stages ← cfg[“STAGE”]
for stage in stages do
sources ← stage[“source”]
sinks ← stage[“sink”]
for s in sources do
discovered wf.add edge(s, stage[“name”])
end for
for s in sinks do
discovered wf.add edge(stage[“name”], s)
end for
end for
if workflow then t> if workflow was input, get the difference
edges ← workflow.get edges()
for e in edges do
if NOT discovered wf.has edge(e[0], e[1]) then
discovered wf.add edge(e[0], e[1], color = “b”)
end if
end for
end if
return discovered wf
6. Transferencia y puesta en producción.
En años recientes, el uso de las tecnologías de la información y comunicación

(TICs) ha jugado un rol importante en el ámbito médico, en la prevención, diagnóstico
y tratamiento de patologías y enfermedades crónicas-degenerativas. En este sentido,
organizaciones médicas construyen y administran sistemas de e-salud para transportar,
procesar y almacenar datos médicos utilizando las TICs disponibles en la organización.
En escenarios reales estos servicios de e-salud deben de hacer frente al reto de manejar

grandes volúmenes de datos de forma eficiente. Otro reto al que deben de hacer
frente las organizaciones para construir estos servicios de e-salud, es el de interconectar
aplicaciones heterogéneas para el procesamiento de datos, que además pueden
estar distribuidas en diferentes computadoras dentro de una organización, o incluso
entre organizaciones. En el presente documento, se describen un conjunto de servicios
de construcción de sistemas de e-salud. Estos servicios permiten la encapsulación y
manejo de aplicaciones como cajas negras llamadas bloques de construcción, las
cuales cuentan con interfaces de entrada y salida para permitir su interconexión para
construir sistemas de e-salud. Estos sistemas de e-salud son independientes de la
infraestructura, y pueden ser desplegados tanto en computadoras personales, como
en clústeres de alto rendimiento y en la nube (por ejemplo, en Amazon EC2 o Google
Cloud). Además, los sistemas de e-salud construidos, así como los bloques de
construcción, son colocados en un repositorio, para permitir bloques construcción y
servicios de e-salud entre organizaciones.
6.1. Constructor de Sistemas de e-salud y analítica de datos clínicos
Las tecnologías de la información como el internet de las cosas (IoT, por sus siglas en
inglés) (Nauman et. al, 2020) (Singh et. al, 2020) así como los algoritmos de análisis de
datos y aprendizaje máquina (Kushwaha et. al, 2020), son consideradas por las
organizaciones y la comunidad científica como un pilar en la construcción de sistemas
de e-salud, los cuales mejoran radicalmente el acceso y eficiencia de los servicios de
salud tradicionales. En este sentido, dichos sistemas son utilizados para adquirir datos
de los pacientes (por ejemplo, signos vitales o actividad) y ayudar a profesionales de
la salud en la toma de decisiones. Además, profesionales de la salud y organizaciones
médicas pueden obtener hallazgos importantes al procesar los datos adquiridos desde
dispositivos IoT, además del procesamiento de imágenes médicas, estudios,
expedientes clínicos y registros históricos de datos (Stanfill et. al, 2020).
Para encontrar estos hallazgos en los datos, las organizaciones deben de procesarlos a
través de un conjunto de tareas a través del ciclo de vida de los datos (Berchick et. al,
2021). En un escenario típico de procesamiento y manejo de datos médicos, estos son
adquiridos de una o distintas fuentes (por ejemplo, de tomógrafos o
electrocardiogramas), posteriormente procesados con algoritmos y aplicaciones (por
ejemplo, para anonimizar imágenes médicas, o procesar los datos utilizando algoritmos
de aprendizaje automático), y finalmente los resultados son visualizados utilizando
herramientas de visualización de datos. En el flujo descrito anteriormente, son utilizadas
un conjunto heterogéneo de aplicaciones, las cuales se encuentran desarrolladas en

distintos lenguajes de programación y para diferentes plataformas. Además,
regularmente dichas aplicaciones son distribuidas en diferentes equipos dentro de la
organización o incluso al exterior de la organización, ya sea utilizando recursos en la
nube o de otra organización (Sánchez-Gallegos, 2021).
En escenarios reales, estas aplicaciones son organizadas en etapas de procesamiento,

y deben de ser ejecutadas automáticamente para soportar el proceso de toma de
decisiones. Además, el intercambio de datos entre cada una de las etapas se debe
de hacer de manera automática y eficiente, desde que los datos son adquiridos hasta
que son entregados a los pacientes o profesionales de la salud. En este sentido, durante
el intercambio y almacenamiento de los datos, diferentes requerimientos no
funcionales deben ser manejados para cumplir con las normas establecidas por la
institución o instancias gubernamentales (Sánchez-Gallegos, 2021).
Crear estas estructuras de forma flexible y portable para permitir la interoperabilidad
de aplicaciones heterogéneas, que además puedan ser desplegadas en diferentes
infraestructuras (por ejemplo, en la nube o una computadora personal) no es una tarea
sencilla.
En el presente documento se presenta un conjunto de servicios de construcción de
sistemas de e-salud para el procesamiento y análisis de datos clínicos. Los servicios de
e-salud construidos con estos servicios de construcción tienen como principales
ventajas las siguientes características:
Modularidad: los sistemas de e-salud se encuentran construidos utilizando

abstracciones conocidas como bloques de construcción. Dichos bloques de
construcción son autónomos e independientes, por lo que no afectan el
funcionamiento de otros bloques, por lo tanto, pueden ser remplazados por otros
bloques de construcción sin necesidad de construir un sistema de e-salud nuevo.
Agnosticidad: tanto los sistemas de e-salud, como los bloques de construcción que
conforman estos sistemas, son agnósticos. Es decir, estos sistemas pueden ser
desplegados en diferentes infraestructuras sin necesidad de hacer cambios en el
código de las aplicaciones. Los sistemas de e-salud pueden ser desplegados en
diferentes plataformas y sistemas operativos, por ejemplo, en sistemas Windows o Linux,
ya sea en una computadora personal o en la nube.
Eficiencia: los sistemas de e-salud construidos integran patrones de paralelismo
implícitos, los cuales mejoran la eficiencia para procesar datos reduciendo los tiempos
de respuesta de las aplicaciones.
Portabilidad: los sistemas de e-salud construidos pueden ser trasladados de una
infraestructura a otra sin requerir hacer cambios en el sistema o las aplicaciones.

Reusabilidad: mediante el repositorio y catálogo de sistemas y aplicaciones, es posible
que una organización reutilicé un sistema de e-salud (o parte de él).
6.2. Esquema de bloques de construcción de flujos de trabajo y servicios

de e-Salud basado en mapas de microservicios y nanoservicios
En la Figura 6.1 se muestra el proceso de construcción automática de sistemas de e-

salud utilizando el esquema de construcción de flujos de trabajo y servicios de e-salud
desarrollado como parte del presente proyecto. El proceso de construcción de
sistemas de e-salud se compone de tres etapas principales, las cuales se encuentran
ilustradas en la Figura 6.1. Estas etapas son: creación de bloques de construcción,
diseño de la estructure de procesamiento, y despliegue de la estructura.
Figura 6.1. Construcción automática de sistemas e-salud.
La primera etapa es la creación de los bloques de construcción. Este proceso consiste

en encapsular en contenedores virtuales el código fuente o ejecutables de la
aplicación que será ejecutada en el bloque de construcción. Además, dentro del
contenedor virtual son colocadas las dependencias de software (librerías, frameworks,

etc.) de la aplicación encapsulada, así como estructuras de control utilizadas durante
tiempo de ejecución para invocar al bloque de construcción.
Estructuras de control
Interfaces de Interfaces de salida

entrada
Aplicación (código fuente o

binario)
Dependencias (librerías,
frameworks, etc.)
Sistema operativo
Figura 6.2. Representación conceptual de un bloque de construcción en Nez.
En la Figura 6.2, se presenta la representación conceptual de los bloques de

construcción manejados en Nez. Como se mencionó anteriormente, los componentes
del bloque de construcción son las estructuras de control que permiten la invocación
del bloque, así como la comunicación con otros bloques. Lo anterior, mediante
interfaces de entrada y salida, ya sea mediante la red o el sistema de archivos. La
aplicación y sus dependencias también son agregadas al bloque de construcción. Esta
aplicación es utilizada para procesar los datos de entrada que lleguen al bloque
durante tiempo de ejecución. Finalmente, al implementar dichos bloques de
construcción como contenedores virtuales, un sistema operativo base debe de ser
especificado, por ejemplo, Ubuntu o Centos.
La segunda etapa para la construcción de sistemas de e-salud, es el diseño de la
estructura de procesamiento del sistema de e-salud. En este paso, los bloques de
construcción son organizados por el diseñador, de tal manera que la salida de una
etapa es la entrada de la siguiente etapa en la estructura. La idea básica de esta
etapa es que el diseñador construya un flujo de trabajo1 interconectado cada uno de
los bloques de construcción y eligiendo las fuentes de datos a procesar. En este sentido,
diferentes patrones de procesamiento pueden ser diseñados. En la Figura 6.3 se
1Un flujo de trabajo es la formalización de un proceso científico o de ingeniería, que permite el despliegue automático de
tareas y aplicaciones en una infraestructura de hardware, por ejemplo, en un clúster privado o en la nube Invalid source
specified..

presentan algunos de los patrones básicos que es posible construir en un flujo de
trabajo. Dichos patrones son:
a) Secuencial: Una actividad en el proceso del flujo de trabajo es ejecutada

inmediatamente después de que la actividad anterior ha sido completada.
b) Paralelo: En algún punto del flujo de trabajo se pueden ejecutar diferentes hilos
para ejecutar actividades en paralelo.
c) Sincronización: Se utiliza cuando dos actividades paralelas convergen en una
tercera actividad.
d) Elección exclusiva: Se da cuando se debe de elegir cuál es la siguiente actividad
en ser ejecutada a partir de un conjunto de actividades candidatas. Para ello se
implementa un conjunto de condicionales en el flujo de trabajo.
e) Mezcla simple: Sucede cuando en algún punto del flujo de trabajo dos o más
actividades, que no se ejecutan paralelamente, se unen sin sincronización.
Figura 6.3. Patrones básicos utilizados en un flujo de trabajo. a) Secuencial. b) Paralelo. c) Sincronización. d)
Elección exclusiva. e) Mezcla simple.
En la tercera etapa, la estructura de procesamiento diseñada es puesta en ejecución.

Para ello se realiza el despliegue automático de los bloques de construcción
(contenedores virtuales) en la infraestructura especificada. En este sentido, la
estructura de procesamiento puede ser desplegada en un solo equipo o en múltiples
equipos.
6.3. Contenerización de aplicaciones para crear bloques de

construcción

Para crear un bloque de construcción, el primer paso es crear contenerizar las
aplicaciones que se utilizarán para crear el sistema de e-salud. Actualmente, los
contenedores son construidos utilizando la plataforma de contenedores Docker2.
En Docker, uno de los métodos para crear contenedores virtuales es mediante la
programación de archivos conocidos como Dockerfile. En estos archivos se declara la
imagen base de la aplicación, y además se configura la imagen de contenedor virtual
indicando la instalación de dependencias de software, así como el directorio de
trabajo dentro del contenedor. Además, los archivos Dockerfile incluyen comandos
para copiar el código fuente o ejecutables desde el sistema de archivos anfitrión al
contenedor virtual.
1. FROM python:3.7.6-buster Imagen base del contenedor.

2.
3. WORKDIR /installation
4. ADD requirements.txt . Instalar requerimientos de la
5. RUN pip install -r requirements.txt aplicación.
6.
7. WORKDIR /app Directorio de trabajo.
8. ADD /code .
9.
10. ADD /API /API
Copia código a la imagen.
11.
12. EXPOSE 5000 Instrucción por ejecutar por el
13. ENTRYPOINT ["python3", "/API/main.py"] contenedor.
Figura 6.4. Ejemplo de un archivo Dockerfile.
En la Figura 6.4 se muestra un ejemplo de un archivo Dockerfile. Como se puede notar,

en el inicio del archivo se indica la imagen de contenedor base de la aplicación.
Ejemplo de imágenes base incluyen ubuntu:18.04, Python:2.04 o centos:6.
Posteriormente, en el archivo se indican los requerimientos que se desean instalar
utilizando comandos como apt-get en Ubuntu, yum install en CentOS, o pip en Python.
6.4. Creación de microservicios y nanoservicios basado en un modelo de

rompecabezas
En Nez, los bloques de construcción son manejados como microservicios o

nanoservicios, dependiendo de las características de la infraestructura donde se
despliegue el bloque de construcción. Por ejemplo, si la infraestructura donde se
2 https://www.docker.com/

despliega está limitada por el hardware o no es posible instalar una plataforma de
contenedores, por ejemplo, en un teléfono inteligente o una computadora personal
antigua, entonces el bloque de construcción puede ser desplegado como un nano
servicio, que básicamente es una plantilla que invoca una función para recibir o enviar
datos. Mientras, que un microservicio es conveniente utilizarlo cuando el bloque de
construcción es desplegado en infraestructura con capacidad para procesar los datos
de entrada, por ejemplo, tomografías o datos de electrocardiograma.
En este sentido, el modelo de construcción en Nez permite el acoplamiento de estos
microservicios y nano-servicios para construir sistemas de e-salud para el
procesamiento de grandes volúmenes de datos. El modelo de construcción está
basado en una metáfora de rompecabezas para la construcción de sistemas de e-
salud angosticos3 de la infraestructura (Sánchez-Gallegos, 2021). En esta metáfora un
bloque de construcción es una pieza de rompecabezas que representa una pieza de
software que incluye componentes modulares, así como estructuras de control que
permiten que la pieza sea independiente del resto, y, por lo tanto, es posible aislar esta
pieza del resto para invocarla desde herramientas externas mediante un API, procesar
datos y obtener los productos resultantes. Además, las interfaces de entrada y salida
(E/S) de la pieza son abstraídas como los dientes y bahías de enchufe de la pieza de
rompecabezas. Estas interfaces de E/S se encargan de manejar los datos recibidos y
producidos por las aplicaciones en la pieza de rompecabezas. En este sentido, los
resultados son entregados a la siguiente pieza en el sistema de e-salud o a un recurso
de almacenamiento, por ejemplo, una red de distribución de contenidos.
Figura 6. 5. Arquitectura de pila de una pieza (a) y su representación conceptual (b).
3Se dice que son agnósticos dado que se encuentran desacoplados de la infraestructura, por lo tanto, es posible migrar los
servicios a otra infraestructura sin hacer cambios en las aplicaciones y sin modificar el comportamiento del sistema de e-
salud.

En la
Figura 6. 5 se muestra la arquitectura en pila (a) de una pieza de rompecabezas y sus

componentes, los cuales son:
a) Capa de acceso: se encarga de verificar los tokens y credenciales de acceso
para garantizar que solo usuarios, piezas y aplicaciones autorizadas tengan
acceso a la pieza y los datos que maneja la pieza, lo cual incluye los datos
recibidos, así como los resultados generados.
b) Interfaces E/S: permiten la interconexión de una pieza con otras piezas de

rompecabezas, así como con aplicaciones externas.
• Bahías de enchufe: se encargan de leer los contenidos o datos que recibe
la pieza de rompecabezas desde una fuente de datos u otra pieza.
• Dientes: escriben los resultados producidos en un resumidero de datos o los
entregan a otra pieza en el sistema de e-salud.
c) Aplicación: es el software que procesará los datos durante tiempo de ejecución.
Este puede ser el código fuente o ejecutable (binarios) de una aplicación.
• Dependencias: son las dependencias de software de la aplicación.
d) Estructuras de control: se encargan de manejar y coordinar la ejecución de la
aplicación contenida en la pieza de rompecabezas.
Figura 6.6. Representación conceptual de la construcción de una malla de servicios basada en la metáfora de
rompecabezas.
En la Figura 6.6, se muestra el proceso de encapsulación de aplicaciones en

contenedores, la composición de múltiples aplicaciones (A, B, C y D) en una pieza de

rompecabeza, así como la creación de una malla de servicios para almacenar e
indexar las piezas construidas por los diseñadores y usuarios de Nez.
En Nez, un rompecabezas representa una estructura de procesamiento que es
construido acoplando diferentes piezas, las cuales son seleccionadas de la malla de
servicios. Cuando la estructura de procesamiento o rompecabezas es desplegada en
una infraestructura se conoce como sistema de e-salud. Un rompecabezas es un
patrón (por ejemplo, una tubería o un flujo de trabajo) que maneja el ciclo de vida de
los productos digitales (por ejemplo, tomografías, rayos x, o datos de
electrocardiograma) producidos por uno o múltiples hospitales. Para exponer una
estructura de procesamiento como un servicio, un rompecabezas incluye estructuras
de control que implementan una estructura de microservicios para el manejo de las
piezas (bloques de construcción y aplicaciones), metadatos (por ejemplo, orden de
ejecución), una API Rest usada para intercambiar mensajes entre las piezas, así como
un API para invocar una red de distribución de contenidos para intercambiar datos
entre las piezas.
Figura 6.7. Representación conceptual de una tubería construida como un rompecabezas.
En la Figura 6.7 se muestra un ejemplo de un rompecabezas construido como una

tubería de piezas. Este rompecabezas incluye cuatro piezas (𝑷𝑨 , 𝑷𝑩 , 𝑷𝑪 , y 𝑷𝑫 )
conectado a una fuente de datos (𝒇𝒖𝒆𝒏𝒕𝒆_𝟏) que procesa los contenidos entrantes y
entregando los resultados a un resumidero de datos (𝒓𝒆𝒔𝒖𝒎𝒊𝒅𝒆𝒓𝒐_𝟏). Como resultado,
este rompecabezas es manejado como un servicio. En este ejemplo, cada una de las
piezas puede estar desplegada en una infraestructura diferente e incluso en diferentes
organizaciones. Por ejemplo, la fuente de datos, puede ser el sistema PACS de una
organización, las imágenes son anonimizadas por la primera pieza (𝑷𝑨 ), y enviadas a
𝑷𝑩 la cual es una pieza en la una instancia en Amazon EC2 y que se encarga de
procesar las imágenes para transformarlas en formato JPG, y entregarlas a la pieza 𝑷𝒄
para el etiquetado de tumores en la imagen. Finalmente, los resultados son entregados
a 𝑷𝑫 el cual es un visualizador en un centro de salud especializado que permite a los
oncólogos consultar las imágenes etiquetadas y descargarlas en su equipo (resumidero
de datos).

6.5. Esquema de construcción de cripto-contenedores de datos y cripto-
contenedores de aplicaciones
Nez implementa un esquema de construcción de cripto-contenedores de datos y

aplicaciones con el objetivo de observar, en forma automática y transparente, las
normas oficiales (NOM-024-SSA3-2010 y NOM-004-SSA3-2012) e internacionales (ISO-
270001-13, COBIT5, NIST) garantizando privacidad, confidencialidad, integridad,
disponibilidad de los contenidos, tolerancia a fallas de servicios/servidores y
trazabilidad. En este sentido, estos esquemas son agregados a las piezas de
rompecabezas que hacen parte de los servicios de e-salud construidos con Nez. Para
distribuir los datos entre diferentes infraestructuras, Nez está conectado con Muyal-
Zamná crea redes de cripto-contenedores de datos y blockchain para verificar que los
sistemas de e-salud intercambien dato de forma segura.
Los requerimientos no funcionales contemplados en estos esquemas de cripto-
contenedores de datos y aplicaciones son: seguridad, confiabilidad y eficiencia. Los
servicios de seguridad son agregados para resolver problemas que surgen cuando los
datos e información son manejados y compartidos con múltiples usuarios a través de
ambientes no controlados. Este es el caso de la nube y en general de modelos de
subcontratación de recursos, donde los usuarios pierden el control físico sobre los datos.
En este contexto, la integridad de datos, confidencialidad de datos y control de
acceso son aspectos de seguridad importantes a considerar.
Los servicios de confiabilidad son requeridos para solucionar problemas relacionados
con fallas en la infraestructura donde los datos son procesados y almacenados. Lo
anterior, dado que las fallas en la infraestructura resultan en que los datos no estén
disponibles para su consulta/descarga. Este requerimiento resulta clave para evitar que
los usuarios y organizaciones sufran de los efectos de no disponibilidad de los datos.
Figura 6.8. Representación conceptual de esquemas para le preparación y entrega de datos en la nube
utilizando cripto-contenedores de datos y aplicaciones.
En la Figura 6.8 se muestra la representación conceptual de una aplicación cliente que

carga contendidos a la nube utilizando los esquemas de cripto-contenedores de datos
(ver lado izquierdo de la Figura). Además, en la Figura también se muestra el cliente de

descarga de contenidos (ver lado derecho de la Figura). Como se puede observar en
la Figura, los esquemas incluyen etapas para agregar requerimientos no-funcionales a
los datos y ejecutar las aplicaciones en forma segura. En este sentido, las etapas
contempladas son: deduplicación e indexamiento para procesar los datos de forma
eficiente, confiabilidad utilizando el algoritmo de dispersión de información (IDA, por
sus siglas en inglés), y la entrega de los datos utilizando técnicas de criptografía para
agregar seguridad a los datos antes de su transporte. La distribución de los datos entre
las diferentes infraestructuras se realiza utilizando una red de distribución de contenidos
construida con Muyal-Zamná. Además, estos esquemas permiten agregar y remover
etapas para generar diferentes tuberías de preparación de datos. Por ejemplo,
agregar un algoritmo de compresión de datos para reducir el volumen de los archivos,
o sustituyendo el algoritmo de cifrado de datos o el tamaño de las llaves. El cliente de
descarga de datos incluye etapas para recuperar los datos preparados y cargados
con el cliente de carga de datos, la verificación de la integridad de los datos
recuperados, y la colocación de estos datos en las computadoras de los usuarios
autorizados para acceder a los datos.
6.6. Esquema de despliegue de sistemas de e-salud independientes de

la infraestructura
Una vez que se han construido los bloques de construcción y diseñado el sistema de e-
salud, lo siguiente es desplegarlos en la infraestructura en donde será ejecutado el
sistema. En este sentido, el sistema y sus bloques pueden ser desplegados tanto en un
solo equipo, ya sea en la nube o en una computadora personal, o de forma distribuida
en un clúster de cómputo de alto desempeño dentro de una organización o
desplegando los bloques en infraestructuras de diferentes organizaciones y/o la nube.
En este sentido, dos tipos de sistemas de e-salud pueden ser desplegados: intra
institucionales e inter institucionales.

Figura 6.9. Ejemplo de un sistema de e-salud intra institucional.
Los sistemas de e-salud intra institucionales son aquellos permiten a las instituciones y
organizaciones de salud procesar e intercambiar datos entre profesionales de la salud
y departamentos dentro la organización u hospital. Por ejemplo, en la Figura 6.9 se
muestra un ejemplo de un sistema de e-salud intra institucional. En este ejemplo, un
técnico radiólogo realiza la captura de tomografías del paciente en el Instituto
Nacional de Rehabilitación. Las imágenes son almacenadas, y el radiólogo las
comparte con oncólogo del instituto para que las valore y de su diagnóstico. En este
sentido, las imágenes antes de ser compartidas con el oncólogo son procesadas
mediante un servicio de e-salud automático construido para anonimizar las imágenes
y etiquetarlas utilizando un modelo de detección de tumores. Los resultados son
entregados al oncólogo de forma automática en su computadora.

Figura 6.10. Ejemplo de un sistema de e-salud inter institucional.
Los sistemas de e-salud inter institucional son creados para compartir datos entre
diferentes instituciones, organizaciones u hospitales. En este tipo de sistemas, los datos
son distribuidos utilizando una red segura de distribución de contenidos, la cual
automáticamente distribuye los datos a los participantes de las organizaciones que
tenga autorización para acceder a los datos. Por ejemplo, en la Figura 6.10 se muestra
un sistema de e-salud inter institucional. Posteriormente, los datos son inyectados
automáticamente en un sistema de procesamiento de e-salud el cual anonimiza los
datos y realiza la generación de una malla 3D de las imágenes DICOM. Los resultados,
son entregados a la red segura de distribución de contenidos, y posteriormente son
automáticamente colocados en las computadoras de los profesionales de salud con
acceso a los datos.
6.7. Principios de diseño de un prototipo para el manejo de servicios de

e-salud

El manejador de servicios de e-Salud se encarga de coordinar y orquestar los servicios
en tiempo de ejecución en la arquitectura de microservicios. Para ello, en este bloque
se tienen un conjunto de servicios que se encargan de controlar el acceso de los
usuarios a los servicios, así como que el intercambio de datos entre las organizaciones
y las aplicaciones se lleve a cabo de acuerdo con las Normas Oficiales Mexicanas. Este
bloque, además incluye servicios de manejo de catálogos mediante el modelo de
publicación/subscripción, un servicio para el intercambio de datos y diagnósticos,
servicios para el análisis de datos médicos y servicios para la adquisición de datos
desde repositorios médicos utilizando protocolos tales como DICOM y HL7.
Figura 6. 11. Arquitectura para el manejo de servicios de e-salud y sus componentes (piezas y rompecabezas).
La realización de este manejador de servicios de e-Salud se basa en una arquitectura

de jerárquica para el manejo de los servicios de e-salud, rompecabezas, así como las
piezas que lo componen. En la Figura 6. 11 se muestra la representación conceptual
de esta arquitectura. Como se puede observar, esta arquitectura está compuesta de
manejadores para la malla de servicios, rompecabezas, piezas y la infraestructura.

En este sentido, la construcción de un sistema de e-salud utilizando esta arquitectura
se compone de las siguientes etapas: etapa de diseño, etapa de construcción, etapa
de despliegue y orquestación, etapa de lanzamiento y coreografía, y la etapa de
ejecución y operación.
En la fase de diseño, los diseñadores de las organizaciones crean un sistema de e-salud
seleccionando un conjunto de piezas y rompecabezas de la malla de servicios
(repositorio de servicios). En el caso de que en la malla de servicios no se encuentre la
aplicación de procesamiento requerida por la organización, los diseñadores pueden
crear una nueva pieza utilizando un esquema declarativo indicando el nombre de la
pieza, su comando de ejecución, y el código fuente de la aplicación incluyendo un
archivo Dockerfile. Las entradas y salidas para cada pieza, así como su orden de
ejecución son establecidas por los diseñadores. Como resultado de esta etapa se
produce un grafo acíclico dirigido, el cual es convertido en un archivo de
configuración en formato YML.
En la fase de construcción, el manejador de malla de servicios recursivamente invoca
a los manejadores de piezas y rompecabezas para la construcción del sistema de e-
salud siguiendo el archivo de configuración creado por el diseñador.
En la fase de despliegue y orquestación, el manejador de malla de servicios crea las
imágenes de contenedor de las piezas consideradas en el archivo de configuración.
En un segundo paso, los manejadores de piezas y rompecabezas leen los metadatos
de manejo de cada componente para preparar su funcionamiento (agregando
aplicaciones y estructuras de control). Además, durante esta fase, un manejador de
patrones crea y acopla los componentes requeridos para crear patrones de
paralelismo al interior de las piezas, con el objetivo de mejorar su eficiencia. Cabe
recalcar, que esta característica puede ser deshabilitada durante tiempo de diseño
por el diseñador.
En la etapa de lanzamiento y coreografía, los manejadores de piezas y rompecabezas
recursivamente realizan el despliegue de los contenedores correspondientes a cada
pieza en el sistema de e-salud. Posteriormente, en esta etapa automáticamente se
realiza el acoplamiento de las piezas siguiendo las entradas y salidas definidas en el
archivo de configuración. Como resultado, en esta etapa se genera un conjunto de
instancias de contenedor organizadas en la forma de un patrón.
En la fase de ejecución y operación, la estructura de procesamiento (sistema de e-
salud) es expuesta como un servicio haciéndola disponible a los usuarios autorizados
para su consumo.
Los manejadores de la infraestructura incluidos en la arquitectura, implementan
clientes y APIs para la comunicación de los manejadores con la infraestructura en
donde se despliegue y opere el sistema de e-salud. Mientras que el manejador de

mallas de servicios controla los servicios resultantes utilizando un modelo de
publicación/suscripción.
6.8. Plataforma web para la construcción de sistemas de e-salud
Con el objetivo de acceder a los servicios previamente descritos para la construcción

y despliegue de sistemas de e-salud, se desarrolló una plataforma web. A través de
esta plataforma, los diseñadores pueden diseñar sus piezas y rompecabezas para
posteriormente materializar un sistema de e-salud desplegando en la infraestructura
disponible en la organización.
6.9. Preliminares
La plataforma web fue desarrollada y probada en un sistema de contenedores Docker,

utilizando como sistema operativo base Ubuntu 18.04. El servicio de despliegue y
acoplamiento de servicios de e-salud fue desarrollado en C++17, mientras que los
clientes de carga y descarga de datos se encuentran desarrollados en Java 8. La lista
de requisitos de software para el funcionamiento de la plataforma es:
• Docker CE4
• Docker Compose5
• Docker Swarm6 (opcional)
Para desplegar la plataforma web, descarga el código fuente de la siguiente

ruta:RUTA. Navegar a la ruta donde se descomprimió el archivo descargado, y ejecutar
el siguiente comando para desplegar la plataforma con Docker Compose:
docker-compose up -d
Los servicios desplegados por Docker Compose, y que se encuentran declarados en el

archivo YML, son los siguientes:
• Servicios de despliegue y construcción de sistemas de e-salud:
4 https://docs.docker.com/get-docker/
5 https://docs.docker.com/compose/
6 https://docs.docker.com/engine/swarm/

• Interfaz web (nombre del servicio: web-gui).
• API de construcción (nombre del servicio: build-api).
• Base de datos de sistemas de e-salud (nombre del servicio: services-db).
• Servicio de despliegue de servicios de e-salud (nombre del servicio:
deployer).
• Servicios de publicación/suscripción y autenticación.
• Servicio de manejo y redireccionamiento de peticiones (nombre del servicio:

apigateway).
• Servicio de autenticación de usuarios (nombre del servicio: auth).
• Base de datos de autenticación (nombre del servicio: db_auth).
• Servicio de publicación/suscripción de catálogos (nombre del servicio:
pub_sub).
• Base de datos del servicio de publicación/suscripción (nombre del servicio:
db_pub_sub).
6.10. Interfaz gráfica web
La plataforma web tiene una interfaz gráfica en el puerto 221017. Una vez que se
ingresa a la plataforma, se debe de iniciar sesión o en caso de no tener una cuenta,
se debe de registrar una nueva. Para registrar la cuenta, se debe de llenar un formulario
con un nombre de usuario, correo electrónico, contraseña y organización a la que
pertenece el usuario. El usuario debe de validar su dirección de correo electrónico. Una
vez realizado lo anterior, el usuario podrá ingresar a la plataforma.
7 Este es el puerto declarado por defecto en el archivo YML. Usted puede cambiar el puerto si lo desea.

Figura 6.12. Menú de navegación de la plataforma web.
Al ingresar a la plataforma, se mostrará un panel de administración y manejo de

sistemas de e-salud. En la Figura 6.12 se muestra el menú de navegación de la
plataforma web. El menú contiene dos secciones principales. La primera sección
permite crear y visualizar los rompecabezas creados (sistemas de e-salud), mientras que
la segunda sección permite manejar los catálogos de datos del usuario y/compartidos
con el usuario.
6.11. Creación de un servicio de e-salud
Para crear un servicio de e-salud, se deben de acoplar un conjunto de piezas de

rompecabezas, definiendo entradas y salidas. Lo anterior generará un rompecabezas
que durante tiempo de ejecución es manejado como un servicio de e-salud, que toma
los datos desde la fuente de datos especificado (un catálogo de datos en la red de
distribución de contenidos o un directorio en el equipo donde se despliegue el sistema
a de e-salud.

Figura 6.13. Interfaz gráfica para la creación de sistema de e-salud.
En la Figura 6.13 se muestra la pantalla para crear un sistema de e-salud. La creación

de estos sistemas se compone de cuatro pasos básicos:
1. Elige tus piezas: en este paso el diseñador elige las piezas que formarán parte del
rompecabezas que será desplegado como un servicio de e-salud. En esta
pantalla, también es posible crear una pieza si esta no existe en el repositorio de
piezas.
Figura 6.14. Formulario para crear una nueva pieza de rompecabezas.

En la
Figura 6.14 se muestra el formulario para crear una nueva pieza de rompecabezas, la
cual es una aplicación encapsulada en un contenedor virtual y que se utiliza para crear
un rompecabezas que al desplegarlo se materializa en un servicio de e-salud. En el
formulario se debe de indicar el nombre de la pieza, el comando que ejecutará la
pieza durante tiempo de ejecución (por ejemplo, python3 app.py), una breve
descripción de la pieza, y finalmente la imagen de contenedor que se usará para crear
el contenedor de la pieza de rompecabezas.
2. Elige tus requerimientos: en este paso el diseñador elige los requerimientos no

funcionales que serán agregados a los resultados del servicio de e-salud al
almacenarlos.
Figura 6.15. Pantalla de selección de requerimientos no funcionales.
En la Figura 6.15 se muestra la pantalla de selección de los requerimientos no

funcionales para agregarlos al sistema de e-salud. Para agregar un requerimiento no

funcional, se debe de agregar la técnica que añade dicho requerimiento, por ejemplo,
compresión de datos para agregar eficiencia en el manejo y almacenamiento de
datos, el patrón manejador/trabajador (manager/worker) para agregar eficiencia al
procesamiento de datos, o AES4SEC para agregar seguridad a los datos. Note que
estos requerimientos son agregados a los datos durante tiempo de ejecución para
intercambiar datos cumpliendo las normas oficiales en el manejo de datos sensibles.
3. Elige tus datos: en este paso el diseñador elige el catálogo de datos que será la
fuente de datos del servicio de e-salud.
En la Figura 6.16 se muestra la pantalla de selección de catálogos del sistema de e-

salud. Los catálogos que se muestran son aquellos creados en el sistema de
publicación/suscripción de la red de distribución de contenidos manejada por Zamná.
El diseñador puede seleccionar de los catálogos que él ha creado (catálogos
publicados) o de los que le han compartido (catálogos suscritos).
Figura 6.16. Pantalla de selección de catálogos para un sistema de e-salud.
En la Figura 6.17 se muestra la pantalla de creación de un catálogo en la red de

distribución de contenidos de Zamná. Para crear el catálogo solo se debe de
especificar el nombre del catálogo así como al grupo al que pertenece.

Figura 6.17. Pantalla de creación de un catálogo.
4. Une tus aplicaciones: en este paso el diseñador ordena y une sus aplicaciones
para definir su orden de ejecución. Los diseñadores pueden crear diferentes
patrones de procesamiento. Al guardar el servicio de e-salud, este puede ser
desplegado ya sea en una computadora personal, en la nube o en un clúster de
computadoras con Docker Swarm.
Figura 6.18. Interfaz gráfica para el acoplamiento de las piezas.
En la

Figura 6.18 se muestra la pantalla en la que los diseñadores pueden acoplar sus piezas
para crear un rompecabezas que posteriormente será desplegado como un sistema
de e-salud. El diseñador solo debe de arrastrar las piezas y unirlas creando el patrón
que dese, por ejemplo, una tubería de procesamiento o un flujo de trabajo con
bifurcaciones. Al guardar el rompecabezas, la plataforma solicitará un nombre para
identificarla.
En la Figura 6.19 se muestra la pantalla de despliegue del sistema de e-salud.

Actualmente hay dos opciones de despliegue, con Docker Compose para desplegarlo
en un solo equipo o con Docker Swarm para desplegarlo en un clúster de
computadoras.
Figura 6. 19. Pantalla de despliegue de un sistema de e-salud.

Figura 6.20. Pantalla de manejo de un sistema de E-salud construido utilizando un modelo basado en rompecabezas
Una vez construido rompecabezas, y desplegado como un sistema de E-salud, podrá

manejar el sistema desde la pantalla que se muestra en la Figura 6.20. Para acceder a
dicha pantalla, se debe navegar a través del menú e ir a Puzzles>List, en donde se
enlistarán los rompecabezas creados (ver Figura 6.21). Posteriormente, dar clic en “See
puzzle”. En la pantalla de manejo del sistema de E-Salud (Figura 6.20) es posible
ejecutar, desplegar y detener el sistema, así como visualizar los resultados producidos
por el sistema en forma de catálogos y publicar el sistema a un usuario para que pueda
reutilizar el sistema de E-Salud y desplegarlo en su infraestructura.
Figura 6.21. Lista de rompecabezas creados.
6.12. Repositorio de servicios de e-salud creados, compartidos y

publicados en la plataforma
El repositorio de servicios y aplicaciones se encarga de manejar y mantener los

diferentes servicios de e-Salud, así como los contenedores de datos y aplicaciones en
un repositorio que puede ser consultado por los desarrolladores mediante las APIs de
programación del Servicio de construcción de servicios. Además, este catálogo se
encarga de manejar el acceso de los desarrolladores a sus servicios y aplicaciones
previamente desarrollados y/o desplegados, con el objetivo de que estos puedan
modificar y reutilizar servicios previamente existentes.

Figura 6..22. Catálogo de sistemas de e-salud, datos, aplicaciones y resultados.
El catálogo de sistemas de e-salud permite a los diseñadores y organizaciones reutilizar

sistemas y piezas creados dentro de la organización o incluso creados por otras
organizaciones cuando estos comparten sus catálogos. Como se puede observar en
la 6.22, dichos catalogo también son utilizados para manejar datos, aplicaciones y
resultados generados en un sistema de e-salud.
Un catálogo de datos contiene aquellos productos producidos por las organizaciones.

Por ejemplo, imágenes médicas, señales de electrocardiogramas o expedientes
clínicos electrónicos. Dichos catálogos de datos son construidos utilizando Muyal-
Tekanaktli, el cual permite a las instituciones compartir, intrainstitucional e
interinstitucionalmente, bases de datos, resultados/información y sistemas de e-Salud
mediante un modelo de publicación/suscripción, en privado y/o público, de
catálogos. a través de intra/internet. Para obtener la fuente de datos de entrada de
un sistema de e-Salud desde Muyal-Tekanaktli, Nez se apoya en Muyal-Zamná, el cual
implemente una red de distribución segura y confiable de datos. En Nez, es posible
observar los catálogos disponibles (ya sea publicados por el usuario o compartidos por
otros usuarios) que un usuario puede utilizar como fuente de un sistema de e-Salud. En
la Figura 6. se muestra el listado de catálogos en Nez.

Figura 6.23. Lista de catálogos disponibles para el usuario
Nez automáticamente crea un catálogo en Muyal-Tekanaktli para cada conjunto de

resultados producidos por cada etapa en el sistema de e-Salud. En la Figura 6.24 se
muestra un ejemplo de catálogos producidos por Nez. Como se puede observar, el
nombre de cada catálogo producido contiene el nombre de la etapa, así como una
estampa de tiempo para identificar al catálogo. Note que cada catalogo es
etiquetado (ver columna Labels) con la etapa en la que los resultados fueron
producidos.
Figura 6.25. Catálogos de resultados producidos por un sistema de E-salud

Finalmente, Nez maneja catálogos de sistemas de e-Salud y aplicaciones, para permitir
que los usuarios y organizaciones compartan estructuras de procesamiento o parte de
ellas. En la Figura 6.26 se muestra un listado de servicios de e-Salud (rompecabezas)
creado con Nez y manejados como catálogos.
Figura 6.26. Lista de servicios de e-Salud
6.13. Sistema de manejo de catálogo de servicios para que los

desarrolladores puedan acceder a cada producto del servicio
Como se mención o anteriormente, Nez maneja un sistema de de catálogo de

servicios. Este permite a los diseñadores y desarrolladores acceder a los sistemas de e-
salud creados, así como a los datos y piezas (aplicaciones) creados previamente
dentro de la misma organización, e incluso por otras organizaciones.

Figura 6.27. Representación conceptual del sistema de manejo de catálogos de servicios.
En la Figura 7.27 se muestra una representación conceptual del sistema de manejo de

catálogo de servicios. Como se puede observar en la Figura, los diseñadores y
desarrollares pueden elegir del catálogo los servicios y aplicaciones que harán parte
de su sistema de e-salud, y que durante tiempo de ejecución serán ejecutadas como
piezas y rompecabezas. En la Figura, los servicios coloreados de verde son aquellos
que el diseñador/desarrollador eligió para crear el servicio de e-salud. De igual manera,
es posible seleccionar las fuentes de datos del sistema de manejo de catálogos de
datos.
Tanto los sistemas de e-Salud como los catálogos de datos y resultados pueden ser
compartidos con otros usuarios mediante un sistema de publicación/suscripción.
Para publicar un catálogo de datos/resultados, se debe de navegar a
Storage>Catalogs. Posteriormente, se debe de hacer clic en el catálogo que se desea
compartir y dar clic en el botón Publish.
Mientras, que para publicar un sistema de e-Salud, se debe de navegar a Puzzles>List,
y posteriormente dar clic en el botón desplegable de cada rompecabezas, y
seleccionar Publish (ver 6.28).

Figura 6.28. Compartir sistema de e-Salud (rompecabezas).
Figura 6. 29. Pantallas de publicación de catálogos y sistemas de e-Salud (rompecabezas).
En la Figura 6.29se muestran las pantallas para compartir tanto catálogos de

datos/resultados como de rompecabezas (sistemas de e-Salud). En dichas pantallas se
debe de seleccionar el usuario al cual se publicará el catálogo o el sistema de e-Salud.
Una vez compartido el catálogo, los usuarios deberán suscribirse a los catálogos que le
han compartido.
6.14. Interfaz de programación de aplicaciones y servicios
Nez permite a los desarrolladores acceder a un conjunto de APIs para la creación y

manejo de sistemas de e-Salud. Además, dichas APIs pueden ser consumidas por
aplicaciones desarrolladas por las organizaciones para obtener el estado de un sistema
de e-Salud o consumir sus resultados, por ejemplo.
6.15. Servicio de descubrimiento, indexamiento y monitoreo de cripto-

contenedores de sistemas de e-Salud
Nez incluye un método para la creación y consumo de representaciones de cripto-

contenedores virtuales construidos utilziando Docker. La idea principal es obtener una
representación de un contenedor virtual Docker que pueda ser consumida por usuarios
diversos (humanos, dispositivos IoT, aplicaciones, contenedores virtuales, etc.) y que

sirva como una herramienta de apoyo para la toma de decisiones en la gestión de los
contenedores virtuales. Para ello es necesario crear un DST (Digital Sentinel Twin -DST-),
este es un objeto de software generado a partir del método propuesto. La
conceptualización de un DST se ilustra en la Figura Figura 6., a continuación, son
explicados los conceptos8.
Una CApp (Container Application -CApp-) representa aquella aplicación que se
encapsula en uno o más cripto-contenedores virtuales. Un vc (virtual container -vc-) es
una pieza de software que ofrece un mecanismo para la encapsulación lógica de
aplicaciones, en el que éstas son independientes del entorno en el que se ejecutan.
Figura 6.30. Conceptualización de un DST.
Un VCS (Virtual Container System -VCS-) representa un conjunto de vci construido como
una única solución (servicio) para realizar una tarea en un flujo de datos. Un VD (Virtual
Device -VD-) representa aquellos dispositivos virtuales que forman parte una CApp. Esto
significa que un V D comprende componentes como V C o V CS.
Por lo tanto, un DST es un objeto de software para interactuar de manera sencilla con
la estructura compleja y detallada de los V D y su CApp. Esto se debe a la flexibilidad
de la WoT card que las representa, la cual cumple con las recomendaciones de W3C
Esta información proviene de una DfE (Dataflow Entity -DfE-), la cual captura
información de cada componente interno (cualquier CApp ∈ vc o vci ∈ V CS). DfE es
básicamente una estructura de datos que incluye información sobre la estructura, el
comportamiento y la función de un V D. La estructura, el comportamiento y la función
se utilizan para modelar el flujo de datos desde el V D hasta los procesos de toma de
decisiones. Se consideró una capa adicional para hacer más accesible la
representación de una DfE utilizando las pautas de WoT; esto produce lo que se
denomina WoT card. Esto significa que una WoT card representa la información de DfE
a través de conceptos utilizados en el dominio de contenedores virtuales. Estos
8 Es importante remarcar que en el resto del documento se emplean acrónimos que se derivan de conceptos en inglés. Se ha
decidido emplear estos acrónimos en inglés para mantener el vínculo con los conceptos empleados en la publicación de este
trabajo en una revista.

conceptos provienen de una ontología9 basada en la norma ISO/IEC JTC 1/SC 3810.
Siguiendo estos estándares de WoT, una WoT card puede representar a un V D de una
manera definida y única.
Figura 6.31. Contexto de un DST.
En la Figura 6.31se ilustra el método para la construcción y consumo de un DST. Se

propone un método de tres fases para la construcción y el consumo de un DST,
tomando en cuenta el flujo de datos desde los V D hasta los procesos de toma de
decisiones. En la Figura 6.31también se muestra la vista conceptual de las etapas del
método: Modelado (etapa 1), donde se adquieren los datos de un V D y se modelan
sus elementos teniendo como resultado una DfE; luego, en la Representación (etapa
2) esta DfE se representa en WoT cards y se almacenan en una base de datos, para
posteriormente ser utilizadas en el Consumo (etapa 3). A continuación, se describe con
mayor detalle cada una de las etapas.
6.16. Etapa 1: Modelado funcional para construir una DfE
9
Una ontología es una definición formal de tipos, propiedades, y relaciones entre entidades que fundamentalmente existen para
un dominio de discurso en particular.
10
www.iso.org/committee/601355.html

Un V D se puede modelar como un proceso para lograr un objetivo. El modelado
funcional (T. E, 1993) (Lind,2014) es adecuado para crear una representación de la
estructura, comportamiento y función. Este enfoque de modelado se ha utilizado,
durante los últimos años, para representar con éxito procesos en múltiples escenarios
(Chandrasekaran, 2000) (Yildirim, 2017) (Umeda, 1990)
En el método propuesto todos los participantes del flujo de datos se modelan como
objetos compuestos de partes de bajo nivel; el objeto tiene un objetivo y sus
componentes contribuyen a lograr juntos ese objetivo al realizar sus tareas. El modelado
funcional permite modelar a todos los participantes en la producción de estos flujos de
datos (como vci, VCS o CApps), que, de hecho, tienen un comportamiento de
procesos encadenados. Este modelo se captura en una DfE, que describe el
comportamiento (propiedades y eventos), la función (tareas) y la estructura
(interconexiones) de todos los participantes en el flujo de datos.
Como paso de preparación, se asume la existencia de un vci (ver VD en la Figura )

ejecutando una transformación de datos (tarea); independientemente del número de
vci internos en un flujo de datos, esto se modela como un DST. Consideremos el caso
más simple, donde un vci se descompone de función, estructura y comportamiento y
se almacena en una DfE. Esta descomposición se representa mediante WoT cards, lo
que hace que la DfE sea un DST listo para consumo. Para el caso de un V CS, ocurre el
mismo proceso por cada vci, integrando funciones individuales como la función
general del DST.
• El objetivo de esta fase es obtener los tres elementos principales de modelado de

un vc:
• Comportamiento, donde se especifican los valores de los atributos de los
componentes, según la función del vc.
• Función, donde se especifica el objetivo principal de un vc y las tareas necesarias
para lograrlo.
• Estructura, donde se especifican los componentes de un vc y las conexiones entre
estos componentes.

Esta fase comienza recibiendo el archivo de configuración de vc, en formato
YAML11. De este archivo se adquieren todos los datos necesarios para representar el
vc.
6.17. Etapa 2: Acceso universal a DST mediante WoT
En este punto, una DfE proporciona una representación de los datos necesarios del vc.
Sin embargo, necesitamos una representación útil para interactuar con un vc; dicha
interacción puede ser de computadora a computadora o de humano a
computadora. Para lograr esta flexibilidad, esta representación se basa en los
principios de Web of Things (WoT)(Guinard, 2016). Esta representación de un vc se
denomina WoT card. Además de la información capturada por una DfE, también se
agregan metadatos del vc a la WoT card. Estos son metadatos que corresponden a la
descripción técnica del vc: direcciones IP, volúmenes, puertos, espacios de nombres,
entre otros.
En el caso de un V CS, dichos elementos se definen de forma recursiva para capturar
datos sobre estructuras y transformaciones utilizadas y realizadas por todo el V CS y sus
componentes (vci), respectivamente. Según las recomendaciones de WoT, la
generación de las WoT cards debe basarse en ontologías.
En este sentido, se definió y creó una ontología (llamada VC Docker FU Ontology12),
que se puede adaptar al contexto de cualquier WoT card en varios escenarios. La VC
Docker FU Ontology se utiliza como referencia en toda la generación de WoT cards
durante la representación de un vc. Esta ontología extiende de dos ontologías, primero
extiende de la VC Docker Ontology13, la cual a su vez extiende de VC ISO Ontology.
VC ISO Ontology fue formalizada por nosotros de acuerdo con la norma ISO/IEC JTC
1/SC 3814, que define todos los conceptos y restricciones de la norma de una manera
abstracta. La VC Docker Ontology, en su versión original, ya define conceptos y
restricciones de contenedores virtuales en el entorno Docker, fue adaptada siguiendo
la VC ISO Ontology; se incluyeron algunos conceptos y restricciones adicionales para
cumplir con la norma ISO. VC Docker FU Ontology agrega conceptos sobre el
comportamiento relacionado con los recursos de infraestructura -CPU, MEM, FS y NET-
11
YAML (Ain’t Markup Language) es un formato de serialización de datos legible por humanos, usado por Docker para configurar
los servicios de su aplicación (mediante docker-compose)
12
Disponible en github.com/adaptivez/VirtualContainerOntology
13
github.com/langens-jonathan/docker-vocab/blob/master/docker.md#config
14
www.iso.org/committee/601355.html

(como niveles de utilización y propiedades de dichos valores), y la función de los
contenedores virtuales (como funciones y tareas).
Técnicamente, una WoT card se basa en una clase abstracta llamada Thing, que es el
objeto base para el modelado en el enfoque WoT. Se basa en la estructura de
representación de Thing
Description (TD)15. Por lo tanto, una WoT card se compone de tres elementos: i)
metadata (de Thing), que contiene interacciones (cómo se puede usar o consumir
Thing); ii) vocabulary, que contiene definiciones de conceptos que se utilizan en la
estructura Thing Description y en la ontología (VC Docker FU Ontology), útil para
interacciones; y iii) URIs, que son útiles para identificar recursos en Thing Description,
éstos son enlaces de Internet que permiten tener acceso a los metadatos de Thing.
6.18. Etapa 3: Consume de DST
Una vez generada y almacenada la WoT card, está lista para el consumo mediante un
DST. Para que el DST sea accesible y consumido, debe convertirse en un intermediario
entre el objeto modelado (vc) y el consumidor. Esto es posible mediante el uso de un
sistema RESTful, que puede procesar solicitudes mediante las acciones HTTP más
comunes: GET, POST, PUT, DELETE. De esta manera, cualquier consumidor que realice
solicitudes de tipo REST puede consumir el DST. El consumo puede ser sobre
propiedades, acciones o eventos.
Cada elemento de la WoT card es universalmente identificado y aceptado por otras
entidades físicas y/o abstractas (p. ej., otros vc, V CS, aplicaciones, dispositivos,
peticiones de humanos, etc.) mediante un URI16.
6.19. Prototipo del servicio
Esta sección se describe la implementación de un prototipo para construir y consumir

un DST, basado en el método propuesto. Los componentes de este prototipo y sus
interacciones se muestran en la Figura 6.32. Los componentes se implementaron como
microservicios (encapsulados en contenedores virtuales), codificados mediante Python
3.0, excepto el componente Observación, que se implementó mediante JavaScript y
PHP debido a la naturaleza de las tareas que se ejecutan. El prototipo fue desarrollado
15
Es el modelo base para describir cualquier cosa de IoT en el enfoque de Web of Things del W3C. Thing Description describe los
metadatos y las interfaces de Things. www.w3.org/TR/wot-thing-description
16
URI (Identificador de recurso universal) identifica en Internet un recurso (página web, imagen, audio, video, archivo, dispositivo
IoT, etc.) de una manera única y universal.

para la plataforma Docker, pero el DST puede ser creado para otras plataformas de
contenedores, como LXC17, FreeBSD jail18, o Solaris Zones19, donde un vc es creado a
partir de un archivo Y ML o Y AML.
Figura 6.32. Componentes del prototipo.
17
https://linuxcontainers.org/lxc
18
https://docs.freebsd.org/en/books/handbook/jails/
19
https://docs.oracle.com/cd/E37929_01/html/E36580/zonesoverview.html

7. Trazabilidad y verificabilidad de contenidos médicos
El sistema de e-Salud contemplado en el presente proyecto permitirá a profesionales

de la salud altamente especializados proveer asistencia médica (medición de factores
de riesgo para enfermedades crónico degenerativas, espirometrías, tele auscultación,
etc) de forma confiable y segura. Debido a lo anterior, es necesario incluir mecanismos
que permitan llevar un control de cada uno de los procesos realizados sobre los
expedientes, así como mecanismos de verificación de estos. Para ello se implementa
el servicio de trazabilidad de los productos procesados en cada una de las cadenas
de valor o flujos de trabajo construidos.
El proceso de trazabilidad juega un papel importante dentro de los flujos de cadenas

de valor debido a que hace referencia a la posibilidad de identificar el origen y las
distintas etapas por las que ha pasado un producto a lo largo de todo su ciclo de vida
(proceso productivo, distribución y logística, hasta llegar a un consumidor final).
Este proceso cumple una parte fundamental dentro del presente proyecto debido a
que permitirá a cualquiera de las entidades involucradas (personal médico y usuarios
finales) acceder a la información de cada una de las etapas por las cuales ha pasado
el contenido digital, verificando si este cumple con las acciones pactadas y que ha
sido procesado por las entidades correctas. Lo anterior posibilita aceptar o rechazar el
expediente digital basado en la información del flujo del producto (traza) apoyando
de esta manera a la toma de decisiones, mejorando la confianza en el resultado
obtenido.
En este sentido se ha diseñado una solución que permita proveer de características de

trazabilidad y verificabilidad para cada uno de los productos que sean procesados a
través de los servicios construidos a través de la plataforma de e- salud. A continuación,
se detalla cada uno de los componentes que integran este servicio.
7.1. Antecendentes.
Se conoce que para crear soluciones de almacenamiento en la nube extremo a

extremo que sean flexibles y eficientes, se cuenta con un diseño y desarrollo de un

enfoque de bloques de construcción (BB) que cuenta con políticas de
encadenamiento para la creación de flujos de trabajo que permiten el transporte de
datos desde dispositivos en la nube. Estas soluciones permiten a los desarrolladores
construir diferentes estructuras como tuberías, pilas y/o grupos de aplicaciones
mediante el encadenamiento de BBs, a través de diferentes interfaces de
entrada/salida (memoria, red, sistema de archivos). Dichas estructuras garantizan, de
forma interna, la confidencialidad y confiabilidad de los datos, así como la
autenticación, el uso compartido y el almacenamiento en la nube privada. Dicha
solución contiene una interfaz gráfica a partir de la cual un usuario puede crear los
flujos de procesamiento necesarios para un objetivo en particular. Cabe mencionar
que dicho sistema genera un archivo de configuración del flujo para su uso en la
creación del presente servicio.
Además, se cuenta con un sistema que apoya en la gestión de la información durante

el ciclo de vida de los datos clínicos a través de un modelo de distribución de productos
digitales inspirado en los principios de la cadena de suministros. Dicho modelo, permite
la gestión de los ciclos de vida de los productos digitales como cadenas de valor. Así
mismo, garantiza la confidencialidad en la entrega de los datos, evitando no repudio
así garantizando la privacidad mediante el uso de técnicas de cifrado por atributos.
A partir de la información provista por el sistema de construcción de servicios de e-

salud descrito anteriormente se debe desplegar de forma automatica un servicio de
trazabilidad del flujo actual.
7.2. Diseño conceptual y de interacción
El servicio de trazabilidad y verificabilidad de contenidos médicos tiene el objetivo de

asegurar el registro inmutable de cada una de las acciones que se realicen sobre cada
uno de los activos digitales que se procesen en las diferentes cadenas de valor
generadas a través del servicio de construcción de servicios de e-salud (detallado
anteriormente).
La figura 8.1 muestra el diseño de interacción entre ambos servicios, el proceso

comienza en el sistema de construcción, en donde el usuario generador de cadenas
define el flujo de procesamiento a través del cual se despliegan las diferentes etapas
que la conforman (cabe destacar que la red de bloques encadenados se despliegue

en el momento inicial del sistema de construcción). A partir de ello el sistema genera
un archivo de configuración que contiene toda la información necesaria para la
configuración, despliegue y ejecución de los elementos requeridos para el uso de la
red de verificabilidad.
El archivo generado contiene una estructura json con la siguiente información:
Figura 7.1 servicio de trazabilidad y verificabilidad
Tomando como base a los puntos anteriormente mencionados, se obtiene un

diagrama conceptual que muestra la interacción de los servicios existentes y el
desarrollado a partir del presente documento.

Figura 7.2 Diagrama de interacción
En la Figura 7.2 se muestra el diagrama de interacción entre el usuario y los diferentes

componentes que integran a la plataforma los cuales se describen a continuación:
• Fase de construcción de servicios: El proceso de construcción de sistemas de -

salud se compone de tres etapas princiaples, creación de blqoues de
construccción, diseño de la estructura de procesamiento y despliegue de la
estructura (cabe mencionar que en este punto se genera el archivo de
configuración a utilizar en el despliegue automatico del servicio de trazabilidad).
Mediante la interfaz web provista un usuario puede hacer uso de estos servicios
sin tener conocimientos técnicos de los bloques utilizados.
• Despliegue automático de servicio de trazabilidad: Esta fase recibe como
entrada un archivo de configuración (descrito anteriormente), a partir del cual
se comienza con el proceso de generación de elementos necesarios en el el
proceso de registro y consultas de transacciones en la red de bloques
encanados. El proceso sigue el siguiente flujo, primeramente, se recibe el archivo
y se envía al componente generar clientes el cual, realiza la construcción y
configuración de los elementos clientes, genera el material criptográfico y
despliega cada uno de ellos en su etapa correspondiente.
• Ejecución: En esta fase se encuentran integradas tanto la ejecución de los flujos
de procesamientos definidos en la fase 1, así como los servicios de trazabilidad,
se observa que en cada una de las etapas involucradas se encuentra inmerso
un elemento cliente de nuestro servicio que permite realizar el registro de la

transacción dentro de la red de bloques encadenados, por lo tanto, cada vez
que un producto pasa por cada una de dichas etapas, este es registrado de
forma inmutable.
A partir del archivo de configuración provisto por el sistema de construcción, el sistema

de trazabilidad crea automáticamente los elementos necesarios para el despliegue de
la solución (se crean los archivos yml de cada uno de los clientes de la red de bloques
encadenados).
Después de haber creado los archivos necesarios para el despliegue, el sistema de

trazabilidad ejecuta cada uno de los archivos ymls generados anteriormente y
comienza con la generación del contrato inteligente para cada una de las cadenas
de valor. Cabe señalar que estos contratos contienen la lógica de negocios pactada
entre las diferentes entidades del flujo de procesamiento.
Además, se crean los componentes criptográficos para cada una de las etapas
involucradas puedan realizar las transacciones correspondientes en cada uno de sus
procesos.
Al final del proceso se generan demonios clientes en cada una de las fases del flujo,
tanto en la extracción como en la carga de información, pudiendo de esta manera
realizar una traza de cada uno de los puntos por los cuales ha pasado cada uno de los
activos procesados. Cabe destacar que se cuenta con una opción de visualización
de las transacciones realizadas a través de una página desplegada junto con la red
de bloques encadenados.

Figura 7.3 Diseño conceptual e interacción
En la Figura 7.3 se observa un diagrama conceptual de alto nivel que muestra el flujo
de la información entre los diferentes componentes de la plataforma. Se puede notar
que a partir del sistema de construcción de servicios se genera un archivo de
configuración mediante el cual se construye el flujo de procesamiento o cadena de
valor, utilizando un enfoque ETL (Por sus siglas en inglés, Extract, Transform, Load) el cual
recibe un activo, lo procesa y lo carga a un espacio definido. Es importante resaltar
que la solución de trazabilidad estará inmerso dentro de cada etapa utilizando tanto
la fuente o extracción de datos así como la carga o sink de estos.
Después de realizar la construcción del flujo, se entrega al servicio de trazabilidad un

archivo de configuración a partir del cual genera las siguientes acciones:

• Genera contratos inteligentes: Contienen la lógica de negocio del flujo de
procesamiento.
• Genera componentes criptográficos: Estos componentes son necesarios para la
verificación y autenticación de los usuarios de la red.
• Generación y ejecución de demonios clientes: Se construyen los elementos
clientes que realizarán las transacciones en la red.
Es importante mencionar que la solución presenta una interfaz web mediante la cual
el paciente o cualquier otro elemento dentro del proceso puede observar la traza de
cada activo y verificar si este ha sido procesado de forma correcta.
7.3. Servicios de trazabilidad

Después de concluir la fase de construcción de servicios de e-salud, se comienza con
el proceso de construcción del servicio de trazabilidad (despliegue automático del
servicio) para lo cual se siguen un conjunto de pasos mostrados a continuación.
Figura 7.4 Flujo de construcción del servicio de trazabilida
1. Configuración de elementos clientes: En este paso se generan los archivos ymls

correspondientes a cada una de las etapas. Cada archivo será construido
para un despliegue simple utilizando docker compose, conteniendo un servicio
cliente y su respectiva base de datos para el almacenamiento interno de los
productos que sean procesados.
2. Generación de contratos inteligentes y material criptográfico: En este paso se
ejecutan los contratos o la lógica del flujo de procesamiento y se generan las
llaves y material necesario para la autenticación del cliente en la red utilizando
el marco de trabajo de Hyperleger Sawtooth.
3. Despliegue de elementos clientes: En este punto se despliegan cada uno de los
archivos generados en el paso 1, esto se realiza utilizando docker compose
para una mejor gestión tanto de servicios como de comunicación.
Por lo tanto, el servicio queda compuesto de los siguientes elementos: red de bloques
encadenados (contiene los servicios necesarios para el registro de transacciones),
generador automático de clientes (construye y despliegue clientes de la red para el
sensado continuo y el registro automático de transacciones) y los clientes.
7.4. Componentes de servicio de trazabilidad.
A continuación, se describen cada uno de los elementos que componen al servicio de

trazabilidad propuesto, estos son: red de bloques encadenados, generador
automático de elementos para el registro de transacciones y clientes.
7.5. Red de bloques encadenados
La red de bloques encadenados es una tecnología que provee una base de datos
distribuida entre nodos participantes, esta base distribuida contiene transacciones
firmadas con criptografía de clave pública lo cual permite identificar el acceso a la
información. Para el registro de transacciones a través de estas tecnologías se utilizan
mecanisos de consenso, el cual una vez realizado se inserta la transacción a la red.
Para el desarrollo de la presente propuesta se utiliza el marco de trabajo de

Hyperledger Sawtooth el cual es una plataforma de blockchain empresarial para la
creación de redes y aplicaciones de enfoque distribuido. Tiene como objetivo
mantener los bloques de forma distribuida y hacer que los contratos inteligentes sean
seguros. Este marco simplifica el desarrollo de aplicaciones blockchain al separar el

sistema central del dominio de la aplicación. De esta manera el personal encargado
de desarrollo puede especificar las reglas de negocios apropiadas para su aplicación,
utilizando el lenguaje de su elección sin necesidad de conocer el sistema central de la

tecnología.
Una característica distintiva de Sawtooth es la separación entre el nivel de aplicación

y el sistema central facilitando el desarrollo y la implementación de una aplicación.
Además, proporciona una abstracción de contrato inteligente que permite escribir la
lógica en en lenguaje de programación de elección. Por último una API REST es
proporcionada y simplifica el desarrollo del cliente al adaptar la comunicación del
validador a HTTP/JSON estándar.
En resumen, las características que se proveen a través de esta tecnología son:
• Base de datos distribuida: La base de datos de la cadena de bloques se

comparte entre participantes potencialmente no confiables y es
demostrablemente idéntica en todos los nodos de la red. Todos los participantes
tienen la misma información.
• Inmutabilidad: La base de datos de blockchain es un historial inalterable de
todas las transacciones que utiliza bloques hash para facilitar la detección y
evitar intentos de alterar el historial.
• Seguridad: Todos los cambios se realizan mediante transacciones firmadas por
identidades conocidas.
• Separación entre el nivel de aplicación y el sistema principal: Sawtooth facilita
el desarrollo y la implementación de una aplicación al proporcionar una
separación clara entre el nivel de la aplicación y el nivel del sistema central.
Proporciona una abstracción de contrato inteligente que permite a los
desarrolladores escribir la lógica del contrato en un idioma de su elección.
• Ejecución de transacciones paralelas: Sawtooth incluye un scheduler paralelo
avanzado que divide las transacciones en flujos paralelos. Según las ubicaciones
en el estado a las que se accede mediante una transacción, Sawtooth aísla la
ejecución de transacciones entre sí mientras mantiene los cambios contextuales.
• Consenso dinámico: en una cadena de bloques, el consenso es el proceso de
construcción de un acuerdo entre un grupo de participantes en una red. Los
algoritmos para lograr consenso con fallas arbitrarias generalmente requieren
alguna forma de votación entre un conjunto conocido de participantes.
Sawtooth abstrae los conceptos centrales del consenso y aísla el consenso de la

semántica de las transacciones. La interfaz de consenso Sawtooth admite la
conexión de varias implementaciones de consenso como motores de consenso
que interactúan con el validador a través de la API de consenso.
7.6. Docker y Docker compose.
Docker es un proyecto (código abierto) que automatiza el despliegue de aplicaciones

dentro de contenedores de software, proporciona una capa adicional de abstracción
y automatización de virtualización de aplicaciones en múltiples sistemas operativos.
Este software nos ayuda a encapsular cada uno de los servicios necesarios
(funcionalidad de la red de trazabilidad, así como de los elementos que permiten el
registro de las transacciones) incluyendo sus dependencias y su lógica de negocio.
Por otro lado, se utilizó compose como herramienta para definir y ejecutar aplicaciones
Docker de varios contenedores, creando una red virtual que permite la comunicación
entre ellos de forma eficiente y simple. Además, a través de un solo archivo yaml nos
permite configurar todos los servicios de la aplicación e iniciar a través de un solo
comando.
7.7. Arquitectura.
Para el desarrollo y despliegue de la red Blockchain se hizo uso del framework

Hyperledger Sawtooth. En Fgura 7.4 se observa a alto nivel cada uno de los
componentes que integran Sawtooth.
• Cliente: Componente externo de la red cuyo objetivo es realizar consultas y

registros del procesamiento del activo. Estos deben autenticarse con las
credenciales generadas para poder hacer uso de la red. Este elemento fue
desarrollado utilizando Javascript y comunicándose con los nodos a través de
peticiones HTTPS.
• REST API: Sawtooth nos provee de una API para realizar las consultas y registros a
la Blockchain de forma simple. Permite a los clientes interactuar con un validador
utilizando peticiones HTTP / JSON comunes. La API REST de Sawtooth está
diseñada solo como una interfaz simple para el uso del cliente. El validador y los
procesadores de transacciones utilizan una interfaz ZMQ / Protobuf que es más

eficiente y robusta, así como un poco más complicada. Este se ejecuta como un
proceso separado, trata al validador como una caja negra, simplemente envía
transacciones y obtiene los resultados. A continuación, se detallan los endpoints
provistos y las características de cada uno para su funcionamiento. AÑADIR LOS
ENDPOINTS
Figura 7.4 Arquitectura Sawtooth
Método Ruta Descripción

Devuelve los agentes
GET /agents registrados en la red
Devuelve el agente que
GET /agents/:publicKey contiene dicha llave pública
Permite la autorización para
el registro de transacciones
a través de credenciales
POST /authorization establecidas
Devuelve la información de
GET /info endpoints de la API
Devuelve los registros
GET /records realizados
Devuelve el registro cuyo Id
GET /records/:recordId sea el provisto

Devuelve el valor de la
propiedad de un registro en
GET /records/:recordId/property/:propertyName particular solicitado
Devuelve el nombre de las
GET /records/:recordId/:propertyName propiedades de un registro
Devuelve el tipo de dato de
GET /record-types los registros
Devuelve el tipo de dato de
GET /record-types/:typeName una propiedad en específico
POST /transactions Registra transacciones
POST /users Registra usuarios
PATCH /users Actualiza los usuarios
Actualiza a un usuario en
PATCH /users/:publicKey específico
• Validador: Componente responsable de validar lotes de transacciones,
combinarlos en bloques, mantener el consenso con la red Sawtooth y coordinar
la comunicación entre clientes, procesadores de transacciones y otros
validadores en la red. Cada una de estas acciones se encuentran inmersas en
los distintos componentes de esta entidad, inter conector, gestor de bloques,
gestor de transacciones, gestor de consenso, estado global y gestión de nodos
en la red.
• Procesador de transacciones: Valida las transacciones y actualiza el estado
según las reglas definidas por la familia de transacciones asociada (contrato
establecido). Cabe mencionar que una transacción es una función que cambia
el estado de la cadena de bloques, cada transacción se coloca en un lote, ya
sea sola o con otras transacciones relacionadas, y luego se envía al validador
para su procesamiento.
7.8. Cliente.
Uno de los componentes clave en este proceso es el cliente, este se encarga de la

conexión entre los flujos de procesamiento y la red de bloques encadenados. Este
elemento es situado en cada una de las entradas y salidas de cada etapa de la
cadena de valor.

Figura 7.5 Entradas y salidas en cadena de valor
En la Figura 7.5 se observa un ejemplo de una cadena de valor de tres etapas, en cada
una de ellas se ejemplifican las entradas y salidas a través del sistema de ficheros. Por
otro lado en la Figura 7.6 se muestra la ubicación de los elementos clientes dentro de
este flujo, se observa que en cada punto de interacción (entrada o salida) se permite
el registro del movimiento a la red de bloques encadenados, por lo que se tiene una
granularidad alta.
Figura 7.6 Ubicación de clientes en cadena de valor
Cada cliente es un proceso que se ejecuta en segundo plano en el equipo en el que

se encuentra cada catálogo relacionado a cada etapa. Dicho proceso es un
demonio el cual contiene un cron que se encarga del sensado de los archivos de la
carpeta especificada, por default el intervalo de tiempo en el bucle es de un minuto,
el proceso sigue el siguiente flujo.
En la Figura 7.7 se observa el diagrama de flujo del demonio cliente el cual al ser
iniciado lee las credenciales provistas por el generador automático de clientes, y
comienza el sensado, cada que el intervalo de tiempo se satisface, el cron realiza:
1. Obtiene ficheros de la ruta especificada.

2. Verifica si existen nuevos ficheros.
a) En caso que existan nuevos ficheros se obtiene la información necesaria del
fichero y se realiza la petición para realizar la transacción a la red (Ver Figura
…)
b) En caso de no existir archivos nuevos no realiza ninguna acción.
3. El proceso se repite indefinidamente.
Figura 7.7 Diagrama de flujo del proceso
En la Figura 7.8 se muestra el flujo de información para realizar una transacción a la red
de bloques encadenados, está comienza desde el cliente quien, al recibir un nuevo
archivo, obtiene sus metadatos y realiza una petición (autenticándose con sus
credenciales) al API. Posteriormente el API envía dicha petición al server de la
Blockchain el cual envía esta instrucción al validador, si la petición de registro es
aceptada, esta se guarda en el estado global del libro.

Figura 7.8 se muestra el proceso para la gestión de material criptográfico
Cada cliente contiene un servicio de base de datos MySQL para el registro interno de
los elementos que ya han sido procesados, este microservicio es puesto como un
sidecar al servicio principal cliente. Además es importante mencionar que el registro
de los activos se basa principalmente en sus metadatos, por lo que es obligadamente
necesario el conservar el nombre del archivo igual en cada una de las etapas. Los
campos que se registran en la cadena de bloques en cada uno de los procesos son:
• Identificador hash del archivo.

• Nombre de fichero.
• Tipo de archivo.
• Subtipo, útil en algunos escenarios en donde se requiere mayor granularidad de
la información.
• Tamaño de archivo.
• Estado, indicando el punto en el cual ha pasado el archivo.
• Hash actual del archivo.
• Hash previo del archivo.
• ¿Es válido?, este campo ayuda a verificar la integridad del fichero en cuestión
ya que verifica a través de los datos Hash si este no ha sufrido alteraciones no
deseadas.

7.9. Generación automática de elementos de interación
Tal como se observa en la Figura 7.1 se requiere de un elemento de generación

automática de clientes para el correcto funcionamiento del servicio de trazabilidad
propuesto. Este generador se dispara en el momento en el que el usuario creador de
servicios de e-salud genera un nuevo flujo, de esta manera el servicio web de
construcción brinda un archivo de configuración el cual contiene toda la información
del flujo de procesamiento (información de etapas como nombres, entradas y salidas).
Con la información anterior el generador automático de clientes comienza a generar

los archivos de despliegues necesarios para la ejecución de cada uno de los servicios.
Como se presente en la Figura 7.9, la solución recibe un archivo de configuración, a
partir de este crea la estructura de ficheros para almacenar los archivos de despliegue,
posteriormente se construyen cada uno de los archivos yamls para la construcción de
los servicios y después de ello se realiza la creación de credenciales y material
criptográfico del usuario. El resultado de este proceso es el sistema completo en
ejecución.

Figura 7.9 componente con sus entradas y salidas
En la Figura 7.10 se observa el diagrama de flujo del proceso que realiza el generador
automático de elementos clientes, el cual recibe como entrada el archivo de
configuración e itera por cada una de las etapas que tiene descritas, por cada una
de ellas crea las carpetas que contienen los archivos de despliegue de los clientes,
además crea el material criptográfico necesario para cada una de estas entidades. Es
en este componente en el cual se realizan los acuerdos necesarios entre etapas para
permitir el registro de las transacciones pactadas, se define un owner de producto, así
como n reporters para el registro de las transformaciones realizadas al activo digital.
Por otro lado, en la Figura 8.11 se muestra el proceso para la gestión de material
criptográfico para cada una de las entidades en el flujo, tal como se observa en la
imagen existen tres unidades involucradas, el generados, el API y la red de cadenas de
bloques.
Primeramente el generador envía una petición de creación de credenciales al API,

para ello envía en una petición POST, información de la etapa (e.g. nombre y
contraseña autogenerada). Posteriormente el API envía una solicitud de creación de
usuarios a la red de bloques encadenados. Esta red crea el material necesario (llave
pública y privada de cada etapa) y envía estas credencials hacia el API, el cual
responde al generador.

Figura 7. 10 Diagrama de flujo del generador de clientes
Es importante mencionar que Sawtooth utiliza secp256k1 como tipo de curva elíptica
ECDSA en el modelo criptográfico y viene definida en el documento normativo
Standards for Efficient Cryptography (SEC). Lo anterior para obtener llaves públicas y
privadas de las entidades.

Figura 7.11 Flujo de proceso de creación de agentes
A continuación, se muestra un ejemplo de credenciales autogeneradas por el

presente componente de la solución de trazabilidad.
{
"username": "myExample",
"password": "ljksdjfio8293889lkjsf", "publicKey":
"02cd3181dbd7d1539f470436ce222c53ab5e514f67809dc0095895e6cdfba97612",
"name": "An entity name",
"email": "myStage@noemail.com", "privateKey":
"2f4175fa39e7d2a89884b492d741a494c2b4f1021d3b3deb7c93ab72cc84935c",
"encryptedKey":
"{
\"iv\":\"h7h0uW9NqLB+VaKM7C8gSA==\",\"v\":1,\"iter\":10000,\"ks\":128,
\"ts\":
64,\"mode\":\"ccm\",\"adata\":\"\",\"cipher\":\"aes\",\"salt\":\"Kn8J+U0
Ko98=\"
,\"ct\":\"w5bGmngbGIt8QIIi/42gVDujsJNUkGsLwmeminMSYIdQq0i+qWZBz
1ZYalxitEsSte7NY
/L/UrDcYE6drcAmSOvQNQdIkwFz\"
}",
"hashedPassword": "slf3UiKJzmcE03wvYFqcHselnMQlDOhhriovzXmGeyk="
};

8. Conclusiones.
Para el Flujo para detección asistida para cáncer de huesos largos, se realizan las
siguientes consideraciones
• El número de batch puede ser mayor si las características del equipo lo permiten.
• Aumentando el número de imágenes puede ofrecer mejores resultados.
• Se puede utilizar otro modelo pre entrenado, s6lo basta con descargarlo y
configurar el pipe-line.con.fig.
Luego de revisar las imágenes facilitadas, es necesario considerar lo siguiente:
Definir las dimensiones de las imágenes. En este documento, mostramos algunas de las
imágenes para ilustrar la variedad de las mismas: algunas son a color, otras en escala
de grises; otras son secuencias de pocas imágenes (i.e., tres) y otras son secuencias de
más de cien imágenes. Es necesario que las dimensiones de las imágenes sean las
mismas para facilitar el desarrollo del modelo de predicci6n de anomalías. El modelo
que se usara para el proyecto está basado en U-Net Para poder usar este modelo, es
necesario que las imágenes de entrada sigan el formato (C, D, H, W) o (Channels,
Depth, Height, Width). Las dimensiones esperadas son (1, D, 512, 512), es decir, una
secuencia de D imágenes de 512x512 de un solo canal (escala de grises). El valor de D
es variable y suele ser cercano a 100.
Definir el contenido de las imágenes. Muchas de las imágenes son tomografías

computadas, es decir, se componen de una secuencia ordenada de imágenes o
cortes. Sin embargo, algunas de las imágenes parecen ser de otro tipo, como el
modelo 3D de la primera fila ,El modelo de predicci6n de anomalías espera
tomografías computadas en escala de grises.
Definir atributos en metadatos. Los archivos DICOM se componen de una matriz de

valores (i.e., la imagen como tal) y de metadatos (i.e., datos del paciente y datos de
la imagen). Para poder generar la secuencia de cortes de una tomografía, es
necesario que el archivo DICOM contenga el atributo SliceLocation para determinar la
posici6n del corte en la secuencia. Notamos que algunas imágenes no tienen este
atributo.

Definir el rango de la escala de Hounsfield. Uno de los pasos recomendados para el
preprocesamiento de las imágenes es delimitar el rango de valores. Por lo que vimos
en las tomografías, el rango es aproximadamente [-3024, 20056). Sin embargo, se suele
reducir este rango para resaltar elementos de la imagen. los autores recomiendan usar
solo el rango [-1000, 1000] para resaltar las masas en tomografías de los pulmones.
El sistema es capaz de identificar tumores en huesos y pulmones, sirviendo de apoyo

en el diagnóstico de cáncer de huesos, indicándole al especialista de la salud las zonas
donde se presume se cuenta con lesiones importantes.
Dada la naturaleza del problema en cuestión, se recomienda utilizar el sistema
únicamente como ayuda en el diagnóstico de cáncer en huesos, y detección de
nódulos en pulmones. Pero no debe utilizarse como sustituto del personal de salud
experto en este tipo de diagnóstico, ya que no será capaz de encontrar cualquier otro
tipo de tumor o lesión relevante para el que no haya sido entrenado, esto con especial
énfasis y cuidado para el modelo de detección de tumores de hueso, dado que
mundialmente no existe una base de imágenes de cáncer de huesos con suficientes
muestras para entrenar un modelo capaz discernir entre pacientes sanos y enfermos, y
los resultados podrían verse limitados. Por lo que, bajo ninguna circunstancia, se debe
descartar la existencia de tumores en pacientes sin el diagnostico de un especialista,
aunque el sistema no haya encontrado lesiones.
9. Anexos
9.1. Manual de Usuario
Manual de Usuario
Autorizaciones

Elaboró: Fernando Balderas Guzmán 15/03/2021
Revisó:
Autorizó:
Control de cambios
Introducción
Este documento provee información relacionada al uso del repositorio de servicios de

e-salud con un enfoque en la aplicación Web. Esto para un mejor entendimiento de
las interfaces gráficas que aparecen en la aplicación. Se muestran las principales
ventanas disponibles en la aplicación, así como una descripción de las mismas.
Objetivo y Alcances
Complementar el desarrollo del repositorio de servicios de e-salud al mostrar las

ventanas de la aplicación, facilitando el uso del sistema al usuario final.
La información técnica, como implementación de los componentes, del sistema no se
muestra en este documento. Si busca esa información favor de revisar el Manual
Técnico.
Guía de uso
Autenticación
La Figura 11.1.1 es la primera ventana en mostrarse, sirve para obtener acceso al

sistema o bien para crear un nuevo usuario. Para iniciar sesión basta con proporcionar
los datos de correo y contraseña, posteriormente dar clic en el botón Sing in. Para crear
un usuario hay que hacer clic en la leyenda Don’t have an account?.
Figura 11.1.1: Ventana de Inicio de sesión
Si se quiere crear un usuario, en la Figura 11.1.2 aparece la ventana con el formulario

de creación. Los parámetros en este caso son: nombre de usuario, correo, contraseña,
confirmación de contraseña, organización (seleccionar) y role (seleccionar). Para
finalizar dar clic en el botón Register.
Nota: Tanto la organización como el rol no se pueden crear mediante la aplicación
Web, solo mediante el uso del API correspondiente.

Figura 11.1. 2: Ventana de Creación de usuario.
La Figura 11.1.3 es la ventana principal del sistema una vez que se ha iniciado sesión.
En ella se muestran las opciones disponibles de interacción, estas son (la barra superior):
contenedores, imágenes y servicios. También se muestra unas tarjetas con accesos
directos a las listas de contenedores, imágenes o servicios según sea el caso. Los
botones de la parte superior despliegan opciones en todos los casos, principalmente
se muestran tres opciones: un listado de elementos (por ejemplo, contenedores),
información de tallada del mismo y una herramienta de creación. Finalmente, a la
izquierda de la barra superior, se muestra el botón de cerrar sesión.
Figura 11.1.3: Ventana Principal.
Contenedores Docker

La Figura 11.1.4 contiene una tabla de los contenedores, la cual tiene las columnas
de: número (#), eliminar (botón), nombre del contenedor, estado, puertos, imagen
base y opciones, en ese orden. Esta ventana tiene los botones para realizar un filtrado
de los contenedores por su estado. También se puede buscar por palabras clave o
palabras incompletas. Cambiar la vista de los contenedores es posible con los botones
a la derecha de la barra de búsqueda.
Figura 11.1.4: Ventana de Contenedores en lista.
La Figura 11.1.5 tiene la ventana de los contenedores con vista de tarjetas.

Prácticamente es la misma información que la vista como lista, pero con la diferencia
de que los contenedores están como tarjetas.

Figura 11.1.5 Ventana de Contenedores en tarjetas.
La Figura 11.1.6 muestra un modal con la información más importante del contenedor
en cuestión. Tiene campos como: el id, nombre, puertos desglosados, estado
desglosado, imagen, fecha de creación, liga para la información detallada y botones
con más opciones para controlar al contenedor. Entre las opciones se encuentran:
detener, pausar y reiniciar.
Figura 11.1.6 Ventana de Opciones del contenedor.

La Figura 11.1.7 proporciona la información detallada de un contenedor. Esta puede
ser accedida al dar clic en las opciones o en el nombre del contenedor. Muestra toda
la información disponible en la plataforma de contenedores docker.
Figura 11.1.7 Ventana de Información detallada del contenedor.
La Figura 11.1.8 muestra opciones de configuración con las que se puede crear un
contenedor. Esto incluye: imagen base, básicas (nombre, comando, puertos), recursos
(como la cantidad y
porcentaje de CPU), red (modo de uso y activar/desactivar), volúmenes (como la

cantidad de lectura y escritura en disco), más opciones avanzadas (dominio, ruta de
inicio, capacidades del kernel, dirección MAC, DNS). No todas las opciones son
requeridas, para crear un contenedor basta con usar las opciones básicas ya que para
más opciones se requiere conocimientos específicos del tema.

Figura 11.1.8 Ventana de Creación de contenedor (opciones avanzadas).
Imágenes Docker
La Figura 11.1.9 contiene un listado de imágenes locales en la parte superior, la parte

inferior corresponde a las imágenes del repositorio (local registry ). La tabla superior tiene
las columnas: número (#), nombre (etiquetas), fecha de creación, tamaño y opciones
(botones borrar y crear contenedor).
Figura 11.1.9 Ventana de Imágenes en lista.

Hacer clic al botón crear contenedor se muestra la Figura 11.10, la cual tiene un
formulario con las opciones mínimas de creación. Estas son: nombre, puertos, volumen,
comando, TTY (botón tipo check ), ejecutar (botón tipo check ). Una vez agregada la
información de los campos, dar clic en el botón Create container para confirmar la
creación.
Figura 11.1.10 Ventana de Creación de contenedor (opciones básicas).
La Figura 11.1.11 contiene la vista de la información detallada de una imagen. Esto

incluye opciones: básicas (hash, arquitectura, capas, etc.), configuraciones en general
(comandos, variables de entorno, volúmenes, etc.) y controlador de graph. Permite
cambiar el contenedor al seleccionar un nombre diferente (botón tipo select ).

Figura 11.11 Ventana de Información detallada de la imagen.
La Figura 11.1.12 muestra el formulario para la creación de una imagen docker. Permite
importar
todos los archivos de contexto desde una carpeta (botón browse). Incluye los campos
de: nombre o etiqueta (tag), codificación (para el formato de envió), tiempo (timeout
), además de otros campos opcionales (botones tipo check ).
Figura 11.1.12 Ventana de Construcción de imagen.

Servicios Contenerizados
La Figura 11.1.13 muestra una tabla de los servicios contenerizados. Esta tiene las
columnas: número (#), nombre, etapas (nombre de las etapas en el servicio), compartir
(botón para publicar el servicio) y acciones (botones). Con los botones de acción se
puede: ejecutar, leer los logs, ir al sistema de supervisión, editar y eliminar. En la parte
superior derecha se encuentra el botón para crear un nuevo servicio.
Figura 11.1.13 Ventana de Servicios en lista.
La Figura 11.1.14 corresponde a la creación de un servicio, muestra un modal para

ingresar el nombre del mismo. Una vez llenado el campo se da clic en el botón Create
para avanzar al panel de edición.

Figura 11.1.14 Ventana de Creación de Servicio.
La Figura 11.1.15 se encuentra como segundo paso para la creación de un servicio (una
vez agregado el nombre del mismo). A la derecha esta´ el panel de edición con los
botones principales de Cancelar y confirmar (Submit), otros botones para las etapas:
crear, habilitar opciones de etapas y limpiar o reiniciar el panel. La parte inferior
izquierda contienen un listado de las etapas disponibles, estas se pueden configurar
(agregarles aplicaciones) y posteriormente arrastrarlas al panel de la derecha para
ligarlas unas con otras (crear una secuencia).
Figura 11.1.15 Ventana de Configuración del Servicio.

La Figura 11.1.16 muestra las opciones de configuración de las etapas. Esto se consigue
al presionar el botón options. Al desbloquear las opciones se muestran tres botones
(agregar aplicación, editar etapa y eliminar etapa) así mismo se bloquea la etapa para
que no se pueda arrastrar. Para poder volver a arrastrar la etapa se presiona
nuevamente el botón options.
Figura 11.1.16 Ventana de Configuración de las Etapas.
La Figura 11.1.17 corresponde a la edición de las aplicaciones y agregarlas a una etapa

seleccionada, esto debido este modal aparece al darle clic al botón agregar
aplicación a la etapa. Esta ventana permite crear (botón New App), editar y eliminar
aplicaciones (botones de la columna Actions). Para agregar una aplicación a la etapa
actual hay que dar clic en el botón verde (Add/Replace App) de la aplicación que se
desea agregar. La parte inferior muestra la aplicación seleccionada en una tarjeta gris.
Los cambios son guardados al dar clic en el botón Submit.

Figura 11.17: Ventana de Configuración de las Aplicaciones.
La Figura 11.1.18 contiene el formulario para crear una nueva aplicación. Basta con
llenar los campos de nombre, imagen (seleccionar), comando, puerto y dar clic en el
botón Submit para confirmar.
Nota: Si no aparecen imágenes disponibles puede existir un fallo en el servicio de
Container Manager.
Figura 11.1.18: Ventana de Creación de Aplicación.
La Figura 11.1.19 muestra como quedaría un servicio compuesto con tres etapas
vinculadas una después de otra en orden consecutivo. Las etapas pueden arrastrarse
del panel izquierdo hacia el derecho cuando se suelta cerca de una tarjeta. Se pueden
retirar las tarjetas al arrastrarlas lejos de la tarjeta vinculada más cercana, así mismo se
pueden retirar varias tarjetas al mismo tiempo. La primera tarjeta corresponde al nombre
del servicio por lo que no se puede retirar, es posible modificar el nombre del servicio al
limpiar el panel. Para finalizar la creación se da clic en el botón Submit.

Figura 11.1.19: Ventana de Agregado de etapas.
La Figura 11.1.20 contiene un ejemplo de los logs que se generan al ejecutar un servicio.
Estos logs se muestran al dar clic en el botón Logs ubicado en la columna Actions de la
tabla de servicios.
Figura 11.1.20 Ventana de Visualización de Logs.
La Figura 11.1.21 muestra como compartir un servicio. Se obtiene al dar clic en el botón
de la columna Share. Esto despliega un modal para seleccionar un usuario con el cual
compartir el servicio. Posteriormente el usuario receptor podrá visualizar que se le

publico dicho servicio, quien después de aceptar el servicio podrá visualizar su
contenido y hacer uso del mismo.
Figura 11.1.21 Ventana de Publicación de Servicio.
9.2. Manual Técnico

Manual Técnico de Instalación
Autorizaciones
Elaboró: Fernando Balderas Guzman 4/10/2021
Revisó: Dr. José Luis González Compeán
Autorizó:
Control de cambios
Introducción
El presente documento busca describir el desarrollo de un repositorio de servicios de e-

salud. Esto mediante un Sistema Gestor de Servicios (SGS) donde un servicio representa
las aplicaciones contenerizadas ya sea de forma individual, así como trabajando en
conjunto para formar cadenas de valor o flujos de trabajo. Presenta el objetivo con los
alcances del sistema, los endpoints de las APIs y los diagramas necesarios para un mejor
entendimiento de sus componentes. Finalmente se muestra el proceso de instalación.
Objetivo y Alcances

Un sistema capaz de generar un repositorio de servicios contenerizados que permita el
CRUD de los mismos, así como su despliegue en diferentes infraestructuras.
Se considera como alcance los servicios empaquetados en contenedores docker así
como su despliegue en docker swarm.
Diagrama de Implementación
Para la implementación del repositorio, los componentes se pueden agrupar en dos

partes: el SGS y un sistema de Supervisión, mostrados en las Figuras 11.2.1 y 11.2.2
respectivamente. La Figura 11.2.1 muestra los componentes de interacción directa con
el repositorio y docker, los cuales son:
• Auth: API encargada de la creación de los usuarios, así como del control de
acceso de estos a los demás componentes.
Tecnologías: PHP, Curl
• Auth DB: Base de datos la guarda la información del API de Auth, la descripción
de sus tablas se muestra en
Tecnologías: PostgreSQL
• Container Manager: API a cargo de las interacciones del SGS con docker, esto
es la creación y obtención tanto de imágenes como de contenedores.
Tecnologías: Python, Docker SDK, SQLAlchemy
• Container Manager DB: Base de datos del API de Container Manager, guarda la
información correspondiente al dicho servicio. Sus tablas se encuentran descritas
en
Tecnologías: SQLite
• Service Manager: API para el manejo de los servicios contenerizados, esto incluye
sus etapas y bloques de construcción.
Tecnologías: PHP, Curl
• Service Manager DB: Base de datos para almacenar la información del API de
Service Manager, sus tablas se encuentran en 5.3.
Tecnologías: PostgreSQL
• Deployer: Componente encargado del despliegue de los servicios registrados en

el componente Service Manager.
Tecnologías: C++, Python, Docker
• Web App: Aplicación Web con interfaces gráficas que mediante interacción con
el resto de APIs permiten al usuario final hacer uso del SGS.
Tecnologías: HTML, CSS, JavaScript, JQuery, AJAX, Bootstrap, Flow
Figura 11.2.1 Elementos del Sistema Gestor de Servicios.
La Figura 11.2.2 corresponde al sistema de supervisión, el cual es un complemento del

SGS, mediante interacciones el SGS provee sus servicios al sistema de supervisión para
obtener el estado de los mismos. Los componentes del sistema de Supervision son los
siguientes:
• Solution Manager: Se encarga de recibir la informacioń de los componentes

mediante un archivo .yml ya sea cargado de disco o recibido por la red.
Tecnolog´ıas: Python, Docker SDK, JSON
• Monitoring: Obtiene y preprocesa las métricas que obtiene del agente cAdvisor,
posteriormente envía las métricas al Indexado.

Tecnologías: Python, cAdvisor, JSON
• Indexing: Sirve de manejador directo con la base de datos de mongo,

proporcionando una manera de interactuar con el almacenamiento de la base
de datos.
Tecnologías: Python, Pymongo, JSON
• MongoDB (Indexing DB): Almacena la información de las métricas, así como de

la información obtenida con el sistema de Supervisión.
Tecnologías: MongoDB
• Risk Observation: Genera el estado del rendimiento de los contenedores

tomando en cuenta un periodo (tiempo) de evaluación.
Tecnologías: Python, Numpy, Pandas, JSON
• Representation: Genera un modelo de la representación del estado de cada

contenedor agregado al sistema, toma en cuenta un estado previamente
obtenido. La modelo esta´ basado en WoT TD.
Tecnologías: Python, JSON, JSON-LD
• cAdvisor: Agente encargado de la obtención de métricas en puro del

rendimiento de contenedores virtuales, así como de equipos físicos sobre los
que se ejecuten contenedores virtuales.
Tecnologías: Go, Docker image
• Web App: Aplicación Web que permite el uso del sistema, así como la
visualización de resultados mediante grafos del estado de los contenedores.
• Tecnologías: HTML, CSS, JavaScript, JQuery, D3.js

Figura 11.2.2 Elementos del sistema de Supervisión
Endpoints
Esta sección corresponde a los enpoints disponibles en las APIs del SGS, siendo estas:
Container Manager (a), Services Manager (b) y Deployer (c). La Tabla 1 muestra la
relacioń que existe entre los componentes, su nombre y puerto mediante los cuales se
puede acceder a ellos en peticiones REST.
Es importante mencionar que tanto las peticiones como las respuestas de las APIs son
en formato JSON. Cada endpoint tiene un recuadro con el método HTTP, la ruta y un
par de estados de respuesta (correcto — incorrecto).
Tabla 11.2.1 Contenedores del SGS y su relación con los nombres de contenedor en Docker
Container Manager
A continuación, se muestran los principales endpoints utilizados en el API de Container

Manager.

a) Inicio de sesión
Listado 11.2.1 Ejemplo de respuesta.
b) Crear usuario
Listado 11.2.2 Ejemplo de respuesta
c) Obtener contenedores docker

d) Crear contenedor

e) Eliminar contenedor
f) Inspeccionar contenedor

g) Ejecutar contenedor
h) Detener contendor

i) Reiniciar contenedor
j) Pausar contenedor
k) Iniciar contenedor

l) Obtener imágenes docker

m) Obtener imágenes Docker del registro
n) Inspeccionar Imagen

o) Cargar Contexto

p) Construir imagen

Service Manager
Los endpoints más importantes del componente Service Manager se describen a

continuación.
a) Crear bloque de construcción
b) Modificar bloque de construcción

c) Obtener Bloques de Construcción

d) Eliminar bloque de construcción

e) Crear Etapa
f) Modificar etapa

g) Obtener etapas

h) Eliminar etapa
i) Agregar bloque de construcción a etapa

j) Crear servicio
k) Modificar servicio

l) Obtener servicios

m) Eliminar servicio
n) Obtener un servicio

o) Ejecutar servicio
p) Leer logs de servicio

q) Publicar servicio a un usuario

r) Obtener servicios publicados a un usuario

s) Subscribir a un servicio publicado
t) Obtener servicios suscritos por un usuario

Deployer
A continuación, se muestra el endpoint disponible en el componente Deploy.
a) Desplegar servicio

Bases de datos y diagramas de relación
Esta sección muestra las bases de datos utilizadas en el SGS, siendo estas las
correspondientes a los siguientes componentes: Auth (a), Container Manager (b) y
Service Manager(c).
a) Auth DB
La Figura 12.2 3 muestra las tablas y las relaciones de la base de datos de Auth.
Figura 12.2.3 Diagrama de ER de la base de datos de Auth.
b) Container Manager DB
La Figura 12.2.4 muestra las tablas y las relaciones de la base de datos de

Container Manager

Figura 12.2.4 Diagrama de ER de la base de datos de Container Manager
c) Services Manager DB
La Figura 12.2.5 muestra las tablas y las relaciones de la base de datos de Services
Manager.

Figura 12.2.5 Diagrama de ER de la base de datos de Service Manager
d) Instalación
Esta sección describe el proceso de instalación que sirve como guía para desplegar
el sistema, así mismo se mencionan algunos requerimientos con los cuales fue
probado el sistema.
Nota: La instalación de los requerimientos no se cubre en este documento. Para la
instalación
de los mismos favores de referirse a los manuales correspondientes.
e) Requerimientos
Sistema operativo Linux

Docker (https://docs.docker.com/get-docker/)
Docker Compose (https://docs.docker.com/compose/)
Docker Swarm (https://docs.docker.com/engine/swarm/)

f) Pasos
a. Obtener el código fuente de los proyectos e-services y supervision (por ejemplo,

clonando los repositorios).
b. Desplegar cada proyecto siguiendo los pasos del README.md, usualmente

ejecutando los archivos compose con el comando docker-compose up -d
dentro de la carpeta raíz.
c. Verificar que se est én ejecutando los contenedores del sistema.

d. Crear las organizaciones y los roles de manera manual utilizando los endpoints
correspondientes. Vease archivo e-services/authpubsub/auth.http.
e. Ahora ya se puede comenzar a utilizar la interfaz gr áfica que por default se
encuentra disponible en http://localhost:22100/

10. Referencias
o Gutiérrez et. al. Software and hardware architecture for a high-availability PACS. JDI, 2012.
o Quezada et. al n, Babel: The Construction of a Massive Storage System, IJWSR,2016 (JCR) IF .6.
o Khan et. al. (2014). Big data: survey, technologies, opportunities, and challenges. Sci. World J.,
2014.
o 4Alva Espinosa et. al. (2014). El expediente electrónico: resultados de la capacitación para su uso
en un hospital de alta especialidad. GMM, 150(s3), 338-346.
o Méndez (2011). Herramientas de seguridad para el paciente: Experiencia en la implementación

del expediente clínico electrónico. Cirujano general, 33(3), 146-150.
o Expediente Clínico Electrónico del IMSS Noviembre de

2011,http://www.dgis.salud.gob.mx/descargas/pdf/4rnis-ece-05.pdf
o Estrategia Digital Nacional. México. http://cdn. mexicodigital. gob. mx/EstrategiaDigital. pdf.
o Morales et. al (2018). A pairing-based cryptographic approach for data security in the cloud. Int.
J. Inf. Secur, 17(4), 441-461.
o Sosa et. al (2020). Improving Performance and Capacity Utilization in Cloud Storage for Content
Delivery and Sharing Services. IEEE T CLOUD COMPUT.
o Sosa et. al, Protecting Data in the Cloud: An Assessment of Practical Digital Envelopes from
Attribute based Encryption, Conference: Special Session on Knowledge Discovery and Cloud
Computing Applications. January 2017.
o Sosa et. al, Protecting Data in the Cloud: An Assessment of Practical Digital Envelopes from
Attribute based Encryption, Conference: Special Session on Knowledge Discovery and Cloud
Computing Applications. January 2017.
o Gonzalez et. al. (2018). Sacbe: A building block approach for constructing efficient and flexible
end-to-end cloud storage. J. Syst. Softw, 135, 143-156.
o Vazquez et. al (2018). CloudChain: A novel distribution model for digital products based on supply
chain principles. IJIM, 39, 90-103.
o Magana et. al, “An Adaptive Cross-Layer Admission Control Mechanism for Telemedicine Services
over the IEEE 802.22/WRAN Standard,” IEICE Trans. Commun., vol. E101.B, no. 4, pp. 1029–1044,
2018, doi: 10.1587/transcom.2017EBP3157

o García et. al(2017). FUX-Sim: implementation of a fast universal simulation/reconstruction
framework for X-ray systems.
o E. Stevens, L. Antiga, and T. Viehmann, Deep Learning with PyTorch. Manning , 2020.
o O. Ronneberger, P. Fischer, and T. Brox, "U-Net: Convolutional Networks for Biomedical Image
Segmentation," 2015.
o J. Huang, V. Rathod, C. Sun, M. Zhu, A. Korattikara, A. Fathi, I. Fisc her, Z. Wojna, Y. Son g, S.
Guadarrama, and K. Murphy, "Sp eed/accuracy trade-offs for modem convolutional object
detectors," 2017.
o T.-Y. Lin, M. Maire, S. Belongie, L. Bourdev, R. Girshick, J. Hays, P. Perona, D. Ramanan, C. L. Zitnick,
and P. Dollar, "Microsoft COCO: Common Objects in Context," 2015.
o A. a. Q. Y. A. a. A. M. a. Z. Y. B. a. A. M. K. a. K. S. W. Nauman, "Multimedia Internet of Things: A

comprehensive survey.," IEEE Access, vol. 8, pp. 8202-8250, 2020.
o R. P. J. M. H. A. &. S. R. Singh, "Internet of things (IoT) applications to Figuraht against COVID-19

pandemic," Diabetes & Metabolic Syndrome: Clinical Research & Reviews, vol. 14, no. 4, pp. 521-
524, 2020.
o S. B. S. B. A. K. K. S. P. J. M. H. A. &. S. R. P. Kushwaha, "Significant applications of machine learning

for COVID-19 pandemic," Journal of Industrial Integration and Management., 2020.
o M. G. K. &. F. S. Stanfill, "Health information management best practices for quality health data
during the COVID-19 global pandemic.," Perspectives in health information management, 2020.
o E. R. &. J. H. Berchick, "Data Processing Improvements for Estimates of Health Insurance Coverage
in the Current Population Survey Annual Social and Economic Supplement.," Medical Care
Research and Review, 2021.
o D. D. D. L. D. K. S. G.-C. J. L. &. M. R. Sánchez-Gallegos, "An efficient pattern-based approach for

workflow supporting large-scale science: The DagOnStar experience.," Future Generation
Computer Systems, vol. 122, pp. 187-203, 2021.
o D. D. G.-M. A. G.-C. J. L. V.-R. S. P.-R. A. E. C.-E. D. &. C. J. Sánchez-Gallegos, "On the continuous
processing of health data in edge-fog-cloud computing by using micro/nanoservice
composition," IEEE Access, vol. 8, pp. 120255-120281, 2020.

o D. D. C.-E. D. R.-A. H. G. G.-C. J. L. C. J. M.-S. M. &. G.-M. A. Sánchez-Gallegos, " From the edge
to the cloud: A continuous delivery and preparation model for processing big IoT data,"
Simulation Modelling Practice and Theory, vol. 105, p. 102136, 2020.
o J. L. G.-C. J. C. H. M. M.-C. A. T. a. R. M. Dante D. Sanchez-Gallegos, "PuzzleMesh: A puzzle model

to build mesh of agnostic services for edge-fog-cloud," Under revision, 2021.
o L. G. G. T. C. &. T. E. Chittaro, «Functional and teleological knowledge in the multimodeling

approach for reasoning about physical systems: a case study in diagnosis.,» IEEE Transactions on
Systems, Man, and Cybernetics, vol. 23, nº 6, pp. 1718-1751., 1993.
o M. &. Z. X. Lind, « Functional modelling for fault diagnosis and its application for NPP,» Nuclear
Engineering and Technology,, vol. 46, nº 6, pp. 753-772, 2014.
o B. &. J. J. R. Chandrasekaran, «Function in device representation.,» vol. 16, nº 3-4, pp. 162-177,
2000.
o U. C. F. &. W. H. Yildirim, «Function modeling using the system state,» AI EDAM, vol. 31, nº 4, pp. 413-
435, 2017.
o Y. T. H. T. T. &. Y. H. Umeda, «Function, behaviour, and structure.,» Applications of artificial

intelligence in engineering , vol. 1, pp. 177-193, 1990.
o D. D. &. T. V. M. Guinard, «Building the web of things: with examples in node. js and raspberry pi,»
Simon and Schuster., 2016.

AI Cancer Reporte-Técnico

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

AI Cancer Reporte-Técnico

Cargado por

Copyright:

Formatos disponibles

Sistema de e-salud para el diagnóstico

asistido de cáncer de hueso largo y

Fecha: 04/10/2021 Publicación: 04/10/2021 Versión: 1.0

Seguimiento Nombre completo Fecha

Elaboró: Ramón Osvaldo Guardado Medina 04/10/2021

Revisó: Dr. Wilfrido Gómez Flores

Autorizó: Dr. José Luis González Compeán

Versión Fecha Bitácora

1.0 04/10/2021 Documento Inicial

Reporte Técnico-Proyecto 41756, Entregable 4.1 Página |1

5.1. Visión artificial .................................................................................................................................. 11

5.2. Preparación de imágenes ............................................................................................................. 13

5.3. Organización de Imágenes ........................................................................................................... 16

5.4. Aumentación de ddatos................................................................................................................ 17

5.5. Etiquetado de Imágenes ............................................................................................................... 18

5.6. Preparación del entorno de programación ................................................................................ 19

5.7. Revision de tensorflow object detection API ................................................................................ 20

5.8. Desarrollo de un modelo de detección de objetos con tensorflow .......................................... 20

5.9. Entrenar el modelo. ........................................................................................................................ 21

5.10. Desarrollo de un modelo de detección de objetos con tensorflow ...................................... 22

5.11. Desarrollo técnico ....................................................................................................................... 25

5.12. Software utilizado ........................................................................................................................ 26

5.13. Descarga de librerías .................................................................................................................. 26

5.14. Extracción de imágenes de archivos DICOM .......................................................................... 26

5.15. Entrenamiento del sistema CADe .............................................................................................. 27

5.16. Generar TF Récords a partir de las imágenes y XML's. ............................................................. 28

5.17. Descargar un modelo pre entrenado. ...................................................................................... 29

5.18. Configurar el pipeline de entrenamiento. ................................................................................ 30

5.19. Entrenar el modelo. ..................................................................................................................... 30

Reporte Técnico-Proyecto 41756, Entregable 4.1 Página |2

5.21. Detección. ................................................................................................................................... 31

5.22. Implementación del servicio para la caracterización de procesos asociados al flujo de

5.23. Requerimientos ............................................................................................................................ 33

5.24. Alcances ...................................................................................................................................... 33

5.25. Entradas ....................................................................................................................................... 34

5.27. Diseño de la solución y complimiento de normas internacionales ........................................ 34

5.28. Preprocesamiento ....................................................................................................................... 35

5.29. Identificación de flujos de trabajo e información de contenedores ..................................... 35

5.30. Determinar cumplimiento de normas........................................................................................ 38

5.31. Descubrimiento de flujo de trabajo ........................................................................................... 39

6. Transferencia y puesta en producción. .............................................................................................. 40

6.1. Constructor de Sistemas de e-salud y analítica de datos clínicos ............................................. 41

6.2. Esquema de bloques de construcción de flujos de trabajo y servicios de e-Salud basado en

6.3. Contenerización de aplicaciones para crear bloques de construcción .................................. 45

6.4. Creación de microservicios y nanoservicios basado en un modelo de rompecabezas......... 46

6.5. Esquema de construcción de cripto-contenedores de datos y cripto-contenedores de

6.6. Esquema de despliegue de sistemas de e-salud independientes de la infraestructura ......... 51

6.7. Principios de diseño de un prototipo para el manejo de servicios de e-salud ......................... 53

6.8. Plataforma web para la construcción de sistemas de e-salud .................................................. 56

6.9. Preliminares ...................................................................................................................................... 56

6.10. Interfaz gráfica web .................................................................................................................... 57

6.11. Creación de un servicio de e-salud........................................................................................... 58

6.12. Repositorio de servicios de e-salud creados, compartidos y publicados en la plataforma 64

Reporte Técnico-Proyecto 41756, Entregable 4.1 Página |3

6.14. Interfaz de programación de aplicaciones y servicios ............................................................ 69

6.15. Servicio de descubrimiento, indexamiento y monitoreo de cripto-contenedores de

6.16. Etapa 1: Modelado funcional para construir una DfE ............................................................. 71

6.17. Etapa 2: Acceso universal a DST mediante WoT ...................................................................... 73

6.18. Etapa 3: Consume de DST .......................................................................................................... 74

6.19. Prototipo del servicio ................................................................................................................... 74

7. Trazabilidad y verificabilidad de contenidos médicos ...................................................................... 76

7.1. Antecendentes. .............................................................................................................................. 76

7.2. Diseño conceptual y de interacción ............................................................................................ 77

7.3. Servicios de trazabilidad ................................................................................................................ 82