Introducción:
La pérdida de archivos DICOM, utilizados en imágenes diagnósticas, representa una problemática sumamente delicada en el ámbito de la medicina y la atención médica. En este artículo, compartiremos un caso auténtico en el que participamos en la recuperación de archivos DICOM, resaltando los procedimientos, comandos y bibliotecas empleados durante el proceso. Es importante destacar que se han alterado nombres, cifras y otros datos de información para preservar la privacidad de las partes involucradas y evitar cualquier coincidencia con casos de conocimiento público.
Motivación:
El propósito de este artículo es proporcionar información y conocimientos que puedan resultar de utilidad para otros profesionales de la salud, ingenieros biomédicos y especialistas en recuperación de datos. La pérdida de archivos DICOM puede acarrear graves consecuencias en el diagnóstico y tratamiento de los pacientes, y el compartir nuestras experiencias y técnicas puede contribuir a abordar esta problemática de manera efectiva.
Descripción del Caso:
En este caso particular, nos enfrentamos a la pérdida de archivos DICOM. Aunque hemos alterado la información para preservar la confidencialidad, la situación se asemeja a numerosas otras que podrían presentarse en el entorno médico.
Capítulo 1: Falla de Discos
En la mañana del miércoles 5 de abril de 2023, el equipo de TI detectó que dos de sus particiones se encontraban inactivas. Una de estas particiones se destinaba a realizar copias de seguridad, enviando archivos DICOM a un almacenamiento offline como parte del proceso de respaldo, mientras que la otra partición se utilizaba activamente como almacenamiento por el PACS, uno de las 10 particiones, cada una con una capacidad de 50 terabytes, totalizando 500 terabytes. La partición relacionada con las copias de seguridad tenía un tamaño de 20 terabytes.
En consecuencia, la información comprometida ascendía a un total de 70 terabytes, sumando la partición de almacenamiento activo de 50 terabytes y las 20 terabytes destinadas a las copias de seguridad. La situación fue informada de inmediato a las áreas pertinentes, como el servicio de atención al cliente, el soporte externo, la administración de PACS y los administradores especializados en la infraestructura del instituto.
Se envió un correo y un ticket de servicio con el siguiente contenido:
"Se ha detectado que los puntos de montaje /dev/sdx y /dev/sdy no son reconocidos por el sistema operativo y están generando errores en sus operaciones de entrada y salida. En un primer vistazo, el sistema de archivos ext4 muestra los siguientes tamaños:
Punto de montaje /pacs/storage/9: 49Z
Punto de montaje /Offline/3: 20Z
A pesar de esta situación, el PACS sigue operativo, pero el proceso de copias de seguridad se ha detenido, y no se puede acceder ni a la partición de almacenamiento ni a la partición de copias de seguridad."
De inmediato, se procedió a examinar los registros de ingreso y los comandos ejecutados en las terminales de los diferentes usuarios. Este es el primer paso ante un incidente de esta magnitud, que implica la revisión exhaustiva de los registros de todo el sistema, teniendo en cuenta el período en el que ocurrió el incidente.
Capítulo 2: Identificación del Fallo - Origen del fallo
El fallo fue atribuido a un error humano. Un técnico con privilegios administrativos, utilizando una conexión remota y simultáneamente ejecutando su software de asistencia en la elaboración de scripts, entre otras tareas, estaba investigando las razones por las cuales la plataforma había experimentado fallas en días previos, afectando la funcionalidad del sistema.
El técnico estaba elaborando un script destinado a verificar la velocidad de escritura y lectura de los discos duros, con el propósito de recopilar datos relevantes sobre la transferencia de datos entre particiones. Sin embargo, el script aún no había sido parametrizado ni se encontraba en una etapa de pruebas. En este contexto, el técnico no se percató de que su software de edición estaba configurado para utilizar una VPN activa. Cuando se activa la VPN, el software de edición establece automáticamente una conexión SSH al servidor, manteniéndolo en línea con el asistente. Esto significa que cualquier comando que se ejecutara con una ruta o dirección al servidor se llevaría a cabo.
Mientras el técnico desarrollaba las líneas de código que serían utilizadas para evaluar la velocidad de transferencia y consultaba la documentación y el uso de los comandos, presionó accidentalmente la tecla F5. Esta tecla ejecutó el comando en la terminal sin previa depuración. Dado que las líneas de código no estaban parametrizadas, se ejecutaron sin restricciones, afectando a las dos particiones mencionadas.
Capítulo 3: Análisis del Comando que Originó el Incidente - Recreación del Incidente
La comprensión y análisis del comando que desencadenó el incidente son cruciales para evaluar su impacto y encontrar posibles soluciones. Además, recrear el incidente nos ayuda a verificar su causa raíz, entender por qué ocurrió y asegurarnos de que no afecte otros recursos o servicios del sistema operativo o la plataforma.
Para lograr esto, recreamos el incidente en un entorno controlado y virtualizado que simula un escenario similar. Durante este proceso, se establecieron pautas clave:
Procedimiento Estricto: Se estableció un procedimiento riguroso para actividades de investigación, mantenimiento u otras en el sistema.
Documentación Integral: Se documentaron todas las acciones realizadas con el fin de prever futuros problemas y fomentar la colaboración entre las áreas involucradas en la investigación y solución de problemas.
Información a Usuarios: Se destacó la importancia de supervisar el uso de herramientas de asistencia cuando tienen acceso a un servidor, y se explicaron los riesgos asociados cuando estas herramientas están en línea con el servidor.
Una vez recreado el incidente y confirmado que no afectaba otros servicios, se procedió a analizar la documentación del comando que causó el problema.
Análisis de la Documentación del Comando: Tras examinar la documentación del comando y conocer todas sus opciones y formas de ejecución, se evaluó el nivel de riesgo en el que se encontraba comprometida la información.
Capítulo 4: Identificación del Daño y Compromiso de la Información
En este caso, la afectación se limitó a los sectores iniciales de las particiones. El comando afectó únicamente las cabeceras, lo que provocó que el sistema operativo no las reconociera ni pudiera explorarlas debido a la alteración del tipo de archivo de sistema. Pasaron de ser EXT4 a un sistema desconocido, dejando las particiones inactivas.
Se concluyó que la información en las particiones permaneció intacta hasta el momento del incidente y que era posible llevar a cabo un procedimiento de rescate. El objetivo principal consistía en habilitar los sectores de inicio de cada partición para restablecer la información sobre el tipo de archivo al que pertenecen y, en consecuencia, habilitar los archivos DICOM.
Capítulo 5: Primeros Obstáculos
El primer obstáculo que enfrentamos fue desmontar las dos particiones. Al hacerlo, el PACS y el sistema operativo presentaron problemas al iniciar. Para superar esto, se tomaron las siguientes medidas:
Al desmontar la partición, se ajustó la configuración de arranque del sistema operativo para que ignorara la ausencia de las particiones.
Se configuró el PACS para que reconociera la falta de la partición X y solo considerara las demás para el almacenamiento.
Sin embargo, surgió otro obstáculo importante: las particiones LVM estaban administradas por un Kernel de la máquina virtual, y las cabeceras de las particiones no se encontraban en las particiones en sí, sino en la configuración del Kernel de la Máquina Virtual. Esto es de vital importancia, ya que cualquier intento de reescribir los sectores de las cabeceras de las particiones afectaría la información y configuración general del kernel de la VM, lo que causaría un daño generalizado.
Por lo tanto, se descartó la posibilidad de reescribir la información de las cabeceras de las particiones como método de recuperación.
Procedimiento:
Evaluación de la Situación: El primer paso fue comprender la magnitud de la pérdida y el contexto en el que ocurrió.
Recuperación de Almacenamiento Físico:
Utilización de Software de Recuperación: Se utilizaron herramientas especializadas de recuperación de datos DICOM para intentar recuperar archivos de manera electrónica. Esto involucró la exploración de sistemas de almacenamiento, incluso en copias de seguridad.
Verificación de la Integridad de los Datos: Una vez que se recuperaron los archivos, se verificó su integridad y se aseguró de que fueran utilizables en el contexto médico.
Conclusiones:
La pérdida de archivos DICOM es un desafío que puede tener graves repercusiones en la atención médica. En este caso, compartimos nuestra experiencia en la recuperación de datos DICOM, resaltando la importancia de la evaluación de la situación, el uso de herramientas especializadas y la colaboración estrecha con el personal médico. Esperamos que este artículo sea de utilidad para quienes se enfrenten a situaciones similares y estén buscando soluciones efectivas.
Nota:
Este artículo se publica con fines informativos y de estudio, y se han modificado nombres, cifras y otros datos de información para proteger la confidencialidad. Para obtener información adicional o consultar detalles específicos sobre el procedimiento y las herramientas utilizadas, no dude en ponerse en contacto con nosotros a través del correo electrónico evingo.sistemas@gmail.com.
Referencias:
[Lista de comandos y bibliotecas utilizados durante el proceso] (Incluir enlaces o detalles sobre recursos específicos utilizados, si corresponde).
