Archivo neutral de proveedores

Tradicionalmente, la necesidad de almacenar imágenes médicas ha sido más común en los departamentos de radiología y medicina nuclear , y se ha implementado mediante sistemas PACS (Sistemas de Control de Activos) especializados y departamentales, que combinan las funciones de gestión y archivo de imágenes en una única solución. Si bien estos sistemas cuentan con interfaces estándar ( DICOM e IHE ) para la ingesta y distribución de imágenes a través de la red y en soportes físicos (como CD), el flujo de trabajo y el rendimiento óptimo para la visualización suelen lograrse mediante software y protocolos propietarios. Además, el almacenamiento persistente "dentro" de un sistema PACS propietario puede no estar estandarizado, el sistema puede no actualizar los archivos almacenados con las últimas actualizaciones de estudios y datos demográficos, ni con las anotaciones almacenadas en la base de datos, y puede extender, abusar o depender de atributos DICOM específicos, tanto estándar como no estándar (privados), en los archivos almacenados.

Con el tiempo, en muchas implementaciones, la infraestructura de almacenamiento subyacente se ha "excluido" del sistema tradicional (PACS) a nivel de hardware y sistema de archivos ( DAS , NAS , SAN ), y en su lugar es suministrada por proveedores de almacenamiento de datos informáticos no específicos de un dominio .

A medida que más especialidades médicas incorporan imágenes en su práctica, surge la necesidad de extender la capacidad de almacenamiento y distribución de imágenes a otros departamentos de toda la organización. Cada vez hay mayor interés en la interoperabilidad a un nivel de aplicación superior, separando los flujos de trabajo, las soluciones de visualización y análisis específicos de cada departamento de la infraestructura de almacenamiento de imágenes, utilizando protocolos estándar que reconocen las imágenes y los metadatos, sin sacrificar el rendimiento de la visualización.

Un factor que complica la situación es que las ofertas de (PACS) están en constante cambio con respecto a las características y la calidad del servicio, y tradicionalmente los usuarios abandonan un proveedor y reemplazan su producto por otro cada 3 a 5 años. Esto genera la necesidad de "migrar" las imágenes y la información asociada a la nueva arquitectura sin pérdida de datos , una tarea compleja a pesar del uso de formatos estándar para la codificación de imágenes. El concepto de VNA teóricamente permite una mayor estabilidad (reutilización y migración menos frecuente) a nivel de archivo, a pesar de la rápida evolución y los cambios a nivel de aplicación superior (visualización y flujo de trabajo). Por supuesto, migrar de un VNA de un proveedor a otro tampoco es trivial, aunque se espera que sea menos frecuente. ^{[ 1 ]}

Un término alternativo para VNA es "PACS Neutral Archive", que tal vez transmita mejor la intención original, pero este término se usa raramente y, para bien o para mal, VNA se ha convertido en la palabra de moda preferida entre clientes y vendedores. ^{[ 2 ]}

Como se mencionó anteriormente, el archivo de imágenes es, naturalmente, en su mayor parte estático; es decir, la mayor parte del contenido de un archivo permanece sin cambios, con solo un número (relativamente) pequeño de estudios agregados cada día, y con pocos cambios y correcciones necesarios.

Desde los inicios de los PACS, se esperaba que se definieran límites de interoperabilidad estándar. ^{[ 3 ]} Los estándares ACR-NEMA, y posteriormente DICOM, surgieron para abordar no solo la necesidad de un formato de archivo estándar, sino también protocolos para el almacenamiento de imágenes desde las modalidades de adquisición hasta los archivos, y para consultar y recuperar imágenes del archivo. Incluso el primer estándar ACR-NEMA de 1985 ^{[ 4 ]} definió las transacciones FIND y GET. ^{[ 5 ]} Es decir, la separación de las estaciones de trabajo y la gestión del flujo de trabajo de los archivos se previó desde el principio. Las primeras demostraciones de DICOM en RSNA, que comenzaron en 1992, utilizaron un llamado "nodo de prueba central", ^{[ 6 ]} que posiblemente fue uno de los primeros archivos neutrales de proveedores basados ​​en DICOM, aunque esa etiqueta no se usaba en ese momento. Los PACS o mini-PACS de desarrollo propio generalmente describían el archivo y la estación de trabajo como entidades separadas. ^{[ 7 ]} Muchos, pero no todos, los PACS comerciales monolíticos continuaron utilizando protocolos propietarios entre sus estaciones de trabajo y archivos integrados, pero la necesidad de admitir estaciones de trabajo de terceros separadas para trabajos especializados, como el procesamiento 3D y la planificación de radioterapia, siempre fue reconocida e implementada utilizando el protocolo DICOM.

En 1998, Erickson y Hangiandreou ^{[ 8 ]} analizaron las ventajas de separar nuevamente la funcionalidad de archivo del PACS monolítico convencional y utilizar la precarga para alimentar el "dispositivo de almacenamiento de interpretación". También describieron la consulta y recuperación de múltiples archivos (de una manera que hoy se denominaría consulta federada) para facilitar el intercambio de imágenes entre empresas. El artículo señaló algunos de los desafíos prácticos de la época, como la relativa ineficiencia de realizar consultas DICOM en tantos archivos múltiples y separar las respuestas relevantes para la precarga, así como los desafíos relacionados con los identificadores de pacientes. Sin embargo, se consideró que la capacidad de tener imágenes en un sistema separado de la estación de trabajo era una funcionalidad importante. Finalmente, Erickson y sus colegas desarrollaron esta idea y la convirtieron en una empresa emergente, TeraMedica ^{[ 9 ]} , en el año 2000, que fue adquirida por Fuji Medical Systems en 2015.

En una de las muchas entradas de blog ^{[ 10 ]} sobre el tema, Michael Gray hace referencia a una descripción temprana del concepto de separar las aplicaciones clínicas de front-end de la función de almacenamiento de back-end, en un artículo de Nadim Daher, analista de mercado de imágenes médicas en Frost & Sullivan. ^{[ 11 ]}

Un hilo de larga duración del foro PACS de la tía Minnie se desvió para discutir el tema de los archivos neutrales entre una audiencia más amplia después de una respuesta de Michael Gray. ^{[ 12 ]}

Un documento técnico de 2009 de Wayne DeJarnette ^{[ 13 ]} es un intento temprano de establecer una definición basada en un conjunto de características requeridas, y su empresa también ha proporcionado una interpretación más reciente. ^{[ 14 ]}

Michael Gray ofrece sus ingredientes esenciales de un VNA en su entrada de blog de 2009, ^{[ 15 ]} haciendo referencia a la lista de verificación de atributos de Acuo, cuya versión más reciente se puede encontrar en el documento técnico de Shannon Werb sobre los atributos de un VNA "verdadero". ^{[ 16 ]}

En 1997, Larry Sitka dejó 3M/Imation tras haber colaborado con Cemax/Icon en la construcción de Archive Manager y un archivo descentralizado llamado IMAS, que nunca llegó a comercializarse, y fundó la empresa Acuo Technologies. Tardaron dos años y tres meses en conseguir el capital necesario para contratar a otros tres ingenieros fundadores de Acuo. Financiada por un inversor privado llamado Jim Jundt, Acuo abrió oficialmente una oficina el 1 de enero de 2000 con cuatro empleados. La empresa se centró en separar las aplicaciones de visualización (PACS) de los dispositivos de gestión y almacenamiento de datos.

Acuo proporcionaba un servicio que permitía la visualización independiente del proveedor a través de un único repositorio central normalizado para todo el contenido de imágenes. El contenido se almacenaba/vinculaba dentro de Acuo mediante mensajería y protocolos, a través del enrutamiento y la asignación de mensajes DICOM. Para PACS, la solución Acuo parecía un único repositorio cuando el contenido provenía de ubicaciones almacenadas localmente o conectadas mediante protocolo. Fue Michael Gray quien, en 2004, acuñó la frase "Archivo neutral del proveedor", haciendo referencia directa a la capacidad de la plataforma Acuo para separar la visualización, la gestión de contenido, la orquestación de mensajes y el almacenamiento. El retorno de la inversión de Acuo se basaba en extraer el archivo de PACS, sin tener que volver a pagar por migraciones (de aplicaciones o almacenamiento) y habilitando el acceso a las mejores aplicaciones de visualización. Neutralidad del proveedor con respecto a las aplicaciones de visualización de PACS y los proveedores de almacenamiento subyacentes.

Muchas organizaciones de prestación de servicios sanitarios siguen beneficiándose del ahorro derivado de esas instalaciones, algunas de las cuales tienen hasta 23 años.  

Herman Oosterwijk ofrece una descripción más reciente en nombre de Teramedica, en su libro blanco ^{[ 17 ]} , donde proporciona una definición más detallada: «Un archivo neutral de proveedor (VNA, por sus siglas en inglés) es un dispositivo médico que ofrece gestión escalable del ciclo de vida de imágenes e información, de modo que las imágenes y la información relacionada puedan consultarse, almacenarse y recuperarse según estándares abiertos en múltiples departamentos, empresas y regiones, manteniendo la privacidad y la seguridad del paciente. Una característica distintiva de un VNA es que proporciona un enfoque centrado en el paciente que trasciende las actualizaciones y los cambios de los diferentes componentes de visualización, adquisición y gestión del flujo de trabajo, ya que estos deben ser intercambiables sin necesidad de migrar, convertir o modificar los formatos de datos o la interfaz del VNA».

La relación entre VNA y el almacenamiento de imágenes médicas en la nube también es nebulosa, aunque ofrece un alto potencial para el cumplimiento de términos de moda , y Michael Gray aporta cierta claridad en su artículo encargado por EMC. ^{[ 18 ]}

Se han descrito varios modelos de despliegue alternativos ^{[ 19 ]} y marcos ^{[ 20 ] que abordan cuestiones de coste, valor y barreras de entrada.}

Dado que el término "VNA" se ha utilizado de forma tan abusiva como término de marketing, ya ha alcanzado un estatus mítico. ^{[ 21 ]}

Un archivo pasivo simplemente almacena lo que recibe y, potencialmente, sobrescribe la misma información cuando la recibe nuevamente con cambios, pero con los mismos identificadores (únicos). Esto resulta insuficiente en un entorno de producción, donde se cometen errores y es necesario corregir los datos demográficos del paciente o subsanar errores (por ejemplo, si se seleccionó un paciente, una solicitud o un lado incorrectos durante un examen, o si hay información errónea en los encabezados de las imágenes).

Existen estándares que cubren algunos casos de uso, como la conciliación de información del paciente (PIR) y la gestión de cambios de objetos de imagen (IOCM) de IHE.

Para que un archivo abarque departamentos, instituciones, regiones o incluso fronteras nacionales, es necesario abordar la cuestión de la identificación de entidades y conceptos.

En general, dentro de un dominio como una institución individual, los identificadores de pacientes y los identificadores de solicitudes, estudios e informes (por ejemplo, mediante números de acceso) se asignan de forma única dentro de ese dominio, pero no fuera de él. La mayoría de los sistemas internos (y la mayoría de los PACS ) no gestionan la existencia de múltiples dominios de identidad, y si se utilizan identificadores en diferentes dominios, se producen colisiones y ambigüedad. Por lo tanto, cada identificador debe estar cualificado por su "autoridad de asignación" cuando se utilice (el enfoque adoptado por el perfil IHE Multiple Image Manager Archive (MIMA) basado en DICOM ) o bien convertirse en un único identificador "canónico" que abarque el ámbito del dominio más amplio que incluye todos los sistemas integrados entre empresas (el enfoque adoptado por IHE Cross Enterprise Document Sharing ). Al importar imágenes externas al archivo local, también debe abordarse este asunto, normalmente asignando el identificador externo a un identificador interno y recodificando la información (conversión) en el "encabezado" DICOM u otros metadatos (como por ejemplo de la forma especificada en el flujo de trabajo de conciliación de importación).

Que la compatibilidad con esta función sea esencial para una VNA depende del entorno en el que se vaya a implementar (dentro de una misma empresa o en varias), pero una compatibilidad sólida ofrece garantías contra futuros cambios en la configuración de la implementación (como fusiones empresariales).

Del mismo modo, los conjuntos de códigos locales utilizados para elementos como los códigos de procedimiento (para "productos solicitables", a diferencia de los códigos de facturación) no están bien estandarizados, y cuando estos resultan útiles en imágenes para controlar el flujo de trabajo y la visualización (como en el caso de los protocolos de montaje), la capacidad de asignarlos también es una función útil.

Uno de los propósitos de un VNA es almacenar información y proporcionarla a múltiples sistemas que pueden tener diferentes requisitos para su uso y expectativas con respecto a características muy específicas de los atributos y valores DICOM almacenados en ellos, tanto estándar como privados.

El concepto de "transformación dinámica de etiquetas" se presenta como una solución al problema de dos sistemas diferentes que esperan valores distintos para el mismo atributo. La "transformación de etiquetas" se refiere al cambio de valores en uno o más atributos (generalmente elementos de datos DICOM en este contexto). Esto puede hacerse de forma estática, en cuyo caso se realiza una única asignación, o de forma dinámica, en cuyo caso se realizan múltiples asignaciones, cada una específica para un receptor determinado.

En su forma degenerada, la capacidad de asignar cualquier etiqueta y valor a cualquier otro es intrínsecamente peligrosa y socava el valor de intentar estandarizar los atributos desde un principio, así como los esfuerzos de los proveedores de modalidades y PACS por utilizarlos "correctamente". Dicho esto, existe variación en la base instalada e incluso en los nuevos productos en cuanto a cómo se utilizan algunos campos, particularmente para formas de imagen altamente específicas y avanzadas, y la correspondiente variación en lo que las aplicaciones avanzadas de visualización y análisis esperan en su entrada. Por consiguiente, esta es una característica popular, a pesar de sus peligros. Algunos argumentarán con vehemencia que es una característica esencial para ser clasificada como VNA.

Esta característica recuerda a lo que es común en el mundo de HL7 versión 2, un llamado Motor de Interfaz, que está diseñado para mapear prácticamente cualquier cosa a cualquier otra cosa, dependiendo del origen y el destino.

Un caso de uso típico consiste en modificar los valores de la Descripción de la Serie proporcionados por las modalidades de adquisición, para permitir que dos sistemas PACS diferentes que comparten los mismos datos utilicen reglas de protocolo de almacenamiento distintas basadas en dicha Descripción de la Serie. Si bien esto podría lograrse de una manera más estandarizada si las modalidades proporcionaran más detalles sobre otros atributos, los protocolos de adquisición y sus códigos estuvieran mejor estandarizados y los motores de protocolo de almacenamiento fueran más flexibles, dadas las limitaciones del estado actual de la técnica, esta sigue siendo útil.

La transformación dinámica de etiquetas es distinta de los cambios de atributos específicos relacionados con la identidad entre dominios y la resolución de códigos (lo que DICOM en PS 3.4 denomina "coerción"), para los cuales existen estándares definidos sobre qué cambiar, cuándo y cómo, y que a menudo involucran actores adicionales como un índice maestro de pacientes, aunque algunos defensores los agrupan y algunos productos los implementan utilizando el mismo mecanismo.

Michael Gray fue uno de los primeros defensores de la transformación de etiquetas y la considera una característica esencial de VNA. ^{[ 22 ]} Una descripción de los casos de uso de la transformación de etiquetas se puede encontrar en el documento técnico de Wayne Dejarnette de 2010. ^{[ 23 ]}

Los discos duros son baratos, aunque la electricidad y el aire acondicionado no lo son, pero, en cualquier caso, el almacenamiento tiene un coste finito, sobre todo cuando se paga por uso en lugar de utilizar una infraestructura local financiada.

Por consiguiente, cuando expiran los plazos de retención médico-legales o la utilidad clínica (como en el caso del fallecimiento de un paciente), muchos usuarios desean poder eliminar sus datos almacenados. Las normas al respecto son complejas y varían según la jurisdicción y la normativa local. Dadas las demandas contrapuestas de financieros, gestores de riesgos, abogados litigantes, investigadores y educadores, llegar a un acuerdo sobre dicha política puede resultar difícil.

En cualquier caso, una función potencialmente útil de VNA es la compatibilidad con criterios de depuración (eliminación) basados ​​en reglas personalizables localmente, ya sea implementando las reglas directamente o respondiendo a las solicitudes de gestión de cambios de objetos de imagen (IOCM) de IHE desde un motor de reglas independiente.

Los analizadores de redes vectoriales (VNA) no deberían tener dificultades para almacenar contenido DICOM, como imágenes e información asociada, como estados de presentación y los denominados "documentos de evidencia", como los informes estructurados DICOM que contienen elementos como mediciones registradas por la modalidad o resultados de posprocesamiento, como los procedentes de CAD .

En un entorno clínico, sin embargo, pueden estar disponibles otros tipos de documentos y objetos masivos que sería conveniente almacenar. La mayoría de los sistemas PACS adoptan el enfoque de convertirlos a DICOM, en algunos casos utilizando objetos destinados a "encapsular" otro tipo de objeto. El ejemplo clásico es un documento escaneado almacenado como un archivo PDF y encapsulado en un objeto PDF DICOM junto con los metadatos suficientes para identificarlo y gestionarlo, como si fuera una imagen. Los VNA deberían admitir este tipo de objetos DICOM encapsulados, y el "encabezado" DICOM proporciona un medio para obtener los metadatos para la indexación, lo que permite realizar consultas y recuperaciones. Michael Gray profundiza en este tema en su documento técnico al respecto. ^{[ 24 ]}

Para otros tipos de objetos, o cuando no hay un objeto de encapsulación DICOM disponible, o cuando no es necesario interactuar con sistemas DICOM, siempre que exista un medio estándar para proporcionar los metadatos necesarios para la indexación, como por ejemplo mediante el uso de mensajes HL7 versión 2 o servicios de registro XDS, entonces, en teoría, un VNA podría almacenar cualquier cosa.

Ciertos tipos de contenido que no son DICOM, como una instancia de documento HL7 CDA que contiene, por ejemplo, un informe radiológico, podrían almacenarse como un XDS, encapsularse primero en un objeto DICOM Encapsulated CDA y almacenarse mediante servicios DICOM, o bien su contenido y encabezado podrían transcodificarse en una instancia de informe estructurado DICOM. Un VNA completo podría tener la capacidad de transcodificar cualquier instancia individual a otro formato según las necesidades del sistema solicitante (lo que se conoce como "transformación de objetos").

En su documento técnico de 2009 se describe el enfoque de Wayne Dejarnette para el almacenamiento de objetos no DICOM en su producto. ^{[ 25 ]}

Existe consenso general en que el formato de archivo DICOM es necesario para las imágenes, y que, cuando estas se comprimen para su archivo o transporte, deben utilizarse esquemas de compresión estándar, no propietarios (sintaxis de transferencia). De hecho, una característica distintiva de la mayoría de los analizadores de redes vectoriales (VNA) frente a muchos sistemas PACS tradicionales es que evitan los formatos internos propietarios que se utilizaban anteriormente por motivos de rendimiento, sin dejar de obtener un buen rendimiento en todas las interfaces.

Las implementaciones pueden variar en cuanto a la gama de esquemas de compresión compatibles, así como en cuanto a si la compresión reversible (sin pérdidas) es obligatoria para fines de archivo médico-legal. También varían en cuanto a la gama de tipos de imágenes específicas de cada modalidad que admiten; si bien muchos archivos admiten, en principio, todos los objetos de información de imagen DICOM, algunos casos extremos, como imágenes de patología de portaobjetos completos y vídeos largos, pueden no ser compatibles. Una característica general de los VNA es intentar preservar todos los atributos tal como se suministraron originalmente, incluidos los atributos privados (propietarios), ya sean de la modalidad de adquisición o añadidos por otras aplicaciones intermedias (como estaciones de trabajo de control de calidad o PACS).

DICOM describe numerosas "Definiciones de Objetos de Información" y "Clases SOP" para el almacenamiento de imágenes con metadatos específicos relacionados con modalidades y aplicaciones particulares, y la lista de estas se amplía a medida que evoluciona la tecnología. Dado que el formato DICOM es inherentemente extensible y todos los objetos nuevos se basan en una codificación y un patrón comunes, un analizador de redes vectoriales (VNA) debería poder almacenar cualquier objeto de imagen DICOM, independientemente de si la Clase SOP es reconocida o nueva. Esto puede lograrse mediante la configuración modificable en campo para agregar nuevas Clases SOP, mediante el análisis del contenido del encabezado de los objetos o simplemente aceptando, almacenando y reproduciendo cualquier dato transferido mediante una operación DICOM C-STORE.