Un Vendor Neutral Archive ( VNA ) es una tecnología de imágenes médicas en la que las imágenes y los documentos (y potencialmente cualquier archivo de relevancia clínica) se almacenan (archivan) en un formato estándar con una interfaz estándar, de modo que se pueda acceder a ellos en un proveedor. de manera neutral por otros sistemas.
Esta terminología se utiliza a diferencia de los sistemas de comunicaciones y archivo de imágenes (PACS) tradicionales , aunque existe un debate sobre dónde se encuentra el límite entre un VNA y un PACS a lo largo del continuo de sus características comunes.
Definición
La definición más simple es "un dispositivo médico que almacena imágenes médicas en un formato estándar con una interfaz estándar, de manera que otros sistemas puedan acceder a ellas de manera neutral al proveedor".
La llamada "neutralidad del proveedor" está implícita en el formato y la interfaz estándar, y la neutralidad es con respecto a los dispositivos específicos del proveedor que producen o consumen esas imágenes (p. Ej., Para visualización, distribución o análisis, con o sin flujos de trabajo específicos, como en cuanto a los informes de radiología, es decir, un PACS ).
Sin embargo, la definición exacta y el conjunto de características son controvertidos y evolucionan a medida que los diferentes proveedores de VNA intentan distinguirse de sus competidores y evitar ser excluidos, y los clientes expresan deseos que van desde lo pragmático hasta lo fantástico.
Existe un acuerdo general sobre las siguientes características clave:
- Almacenamiento de imágenes DICOM y objetos compuestos relacionados (estados de presentación, objetos clave, informes estructurados)
- Interfaz estándar de red DICOM para almacenamiento, consulta y recuperación
- Actualizaciones y correcciones administrativas (cambios en la identificación del paciente y fusiones de estudios)
- Escalabilidad
Cada una de las siguientes características sigue siendo controvertida, en el sentido de que algunos clientes y proveedores afirman que algunas o todas son fundamentales para el concepto, pero otros no están de acuerdo:
- Almacenamiento de objetos que no están directamente relacionados con imágenes (como solicitudes e informes generados por humanos)
- Almacenamiento de contenido no DICOM (como documentos HL7 CDA )
- Protocolos de acceso que no son DICOM (como IHE Cross-Enterprise Document Sharing ( XDS y XDS-I)
- Resolución de código e identidad entre dominios (identificación del paciente, número de acceso, códigos de procedimiento)
- Transformación dinámica de etiquetas DICOM
- Gestión del ciclo de vida de la información
- Exclusión del contenido de la base de datos de gestión del flujo de trabajo
- Independencia de la elección del motor de base de datos
- Pista de auditoría de acceso
Historia
Evolución
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 en forma de subespecialidades y departamentos (PACS), que han combinado las funciones de gestión de imágenes y archivo de imágenes en una solución única. Si bien todos estos sistemas tienen interfaces estándar ( DICOM e IHE ) para la ingestión y distribución de imágenes a través de la red y en medios físicos (como CD), normalmente el flujo de trabajo y el rendimiento óptimo para la visualización se logran utilizando software y protocolos patentados. Además, el almacenamiento persistente "dentro" de un PACS propietario puede no estar en una forma estándar, el PACS puede no actualizar los archivos almacenados con el estudio más reciente y las actualizaciones demográficas y anotaciones almacenadas en la base de datos, y puede extenderse, abusar o depender de atributos DICOM estándar y no estándar (privados) específicos en los archivos almacenados.
Con el tiempo, en muchas implementaciones, la infraestructura de almacenamiento subyacente se ha "factorizado" fuera de la tradicional (PACS) a nivel de hardware y sistema de archivos ( DAS , NAS , SAN ) y, en su lugar, se suministra mediante datos informáticos no específicos del dominio. proveedores de almacenamiento .
A medida que más especialidades médicas incorporan imágenes en su práctica, surge la necesidad de ampliar la capacidad de almacenamiento y distribución de imágenes a otros departamentos de toda la empresa. Cada vez más existe el deseo de interactuar a un nivel de aplicación más alto, separando los flujos de trabajo específicos de los departamentos, las soluciones de visualización y análisis de la infraestructura de almacenamiento de imágenes, utilizando protocolos estándar que son conscientes de las imágenes y los metadatos, sin sacrificar el rendimiento de la visualización.
Un factor de complicación es que las ofertas (PACS) están en un estado de cambio constante 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-5 años. Esto desencadena la necesidad de "migrar" las imágenes y la información asociada a la nueva arquitectura sin pérdida de datos, una tarea no trivial a pesar del uso de formatos estándar para la codificación de imágenes. El concepto de un 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 cambio en el nivel de aplicación superior (visualización y flujo de trabajo). Por supuesto, la migración de un VNA de un proveedor a otro tampoco es trivial, solo que con suerte es menos frecuente. [1]
Un término alternativo para un VNA es "Archivo Neutral PACS", que quizás transmite 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]
Literatura
Como se señaló anteriormente, el archivo de imágenes es naturalmente en su mayor parte estático, es decir, la mayor parte del contenido de un archivo no se modifica, con solo una (relativamente) pequeña cantidad de estudios agregados cada día, con pocos cambios y correcciones requeridas.
Desde los primeros días de PACS, se esperaba que fuera necesario definir los límites de interoperabilidad estándar. [3] Los estándares ACR-NEMA, y más tarde 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 modalidades de adquisición hasta archivos, y para consultar y recuperar imágenes del archivo. Incluso el primer estándar ACR-NEMA de 1985 [4] definía las transacciones FIND y GET. [5] Es decir, desde el principio se previó la separación de las estaciones de trabajo y la gestión del flujo de trabajo de los archivos. Las primeras demostraciones de DICOM en RSNA a partir de 1992 hicieron uso de 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 estaba en uso en ese momento. Los PACS o mini-PACS de cosecha propia describían típicamente el archivo y la estación de trabajo como entidades separadas. [7] Muchos, pero no todos, los PACS comerciales monolíticos continuaron haciendo uso de protocolos propietarios entre sus estaciones de trabajo y archivos integrados, pero la necesidad de admitir estaciones de trabajo de terceros independientes para trabajos especializados, como procesamiento 3D y planificación de radioterapia, siempre fue reconocidos e implementados mediante el protocolo DICOM.
En 1998, Erickson y Hangiandreou [8] discutieron las ventajas de separar una vez más la funcionalidad de archivo del PACS monolítico convencional y hacer uso de la búsqueda previa para poblar el "dispositivo de almacenamiento de interpretación". También describen la consulta y recuperación de varios archivos (de una manera que ahora se llamaría consulta federada) para proporcionar intercambio de imágenes entre empresas. El artículo señaló algunos de los desafíos prácticos en ese momento, como la relativa ineficacia de realizar consultas DICOM en archivos tan múltiples y separar las respuestas relevantes para la búsqueda previa, así como los desafíos de los identificadores de pacientes. No obstante, se consideró que la capacidad de tener imágenes en un sistema separado de la estación de trabajo era una capacidad importante. Finalmente, Erickson y sus colegas desarrollaron esto en una empresa de nueva creación, TeraMedica [9] en 2000, que fue comprada por Fuji Medical Systems en 2015.
En una de las muchas entradas de blog [10] sobre el tema, Michael Gray hace una 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, un médico Analista de mercado de imágenes en Frost & Sullivan. [11]
Un hilo del Foro de la Tía Minnie PACS de larga duración 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 informe 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 compañía 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 forma más reciente se puede encontrar en el libro blanco de Shannon Werb sobre los atributos de un VNA "verdadero". [dieciséis]
Herman Oosterwijk proporciona una descripción más reciente en nombre de Teramedica, en su informe técnico, [17] en el que ofrece una definición más detallada: "Un archivo de proveedor neutral (VNA) es un dispositivo médico que proporciona una imagen e información escalables y un ciclo de vida para que las imágenes y la información relacionada puedan consultarse, almacenarse y recuperarse de una manera definida por estándares abiertos en múltiples departamentos, empresas y niveles regionales, mientras se mantiene la privacidad y seguridad del paciente. La característica de una VNA es que proporciona un paciente -enfoque centrado que trasciende las actualizaciones y cambios de los diferentes componentes de visualización, adquisición y gestión del flujo de trabajo, ya que deberían ser intercambiables sin tener que migrar, convertir o cambiar los formatos de datos o la interfaz del VNA ".
La relación de VNA con el almacenamiento de imágenes médicas en la nube también es nebulosa, aunque ofrece un alto potencial para el cumplimiento de las palabras de moda , y Michael Gray proporciona cierta claridad en su artículo encargado por EMC. [18]
Se han descrito varios modelos de implementación [19] y marcos [20] alternativos , que abordan cuestiones de costo, valor y barreras de entrada.
Dado que se ha abusado tanto del término "VNA" como término de marketing, ya ha alcanzado un estatus mítico. [21]
Características
Actualizaciones y correcciones administrativas
Un archivo pasivo simplemente almacenará lo que recibe y, potencialmente, sobrescribirá lo mismo cuando se reciba nuevamente con cambios pero con los mismos identificadores (únicos). Esto es insuficiente en una operación de producción, donde se cometen errores, y es necesario corregir los datos demográficos del paciente o corregir los errores (se seleccionó el paciente, la solicitud o el lado incorrectos durante un examen y la información incorrecta está presente en los encabezados de las imágenes).
Existen estándares que cubren algunos casos de uso, como IHE Patient Information Reconciliation (PIR) y Imaging Object Change Management (IOCM).
Identidad entre dominios y resolución de código
Para que un archivo abarque departamentos, instituciones, regiones o incluso fronteras nacionales, se debe 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 solicitud, estudios e informes (por ejemplo, por números de acceso) se asignan de forma única dentro de ese dominio, pero no fuera. 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 todos los dominios, se producen colisiones y ambigüedad. Por lo tanto, cada identificador debe ser calificado por su "autoridad de asignación" cuando se utiliza (el enfoque adoptado por el perfil IHE Multiple Image Manager Archive (MIMA) basado en DICOM ) o coaccionado en un único identificador "canónico" que abarca el alcance de la Un dominio más grande 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, este asunto también debe abordarse, generalmente asignando el identificador externo a un identificador interno y re -codificar la información (coerción) en el "encabezado" DICOM u otros metadatos (por ejemplo, de la manera especificada en el Flujo de trabajo de reconciliación de importación).
Si el soporte para esto es una característica esencial para un VNA depende del entorno en el que se pretende implementar (dentro de una empresa o entre empresas), pero un soporte robusto proporciona un seguro contra futuros cambios de configuración de implementación (como fusiones empresariales).
Del mismo modo, los conjuntos de códigos locales que se utilizan para cosas como los códigos de procedimiento (para "pedidos", en contraposición a los códigos de facturación), no están bien estandarizados y, cuando son útiles en imágenes para impulsar el flujo de trabajo y la visualización (como protocolos colgantes), la capacidad de mapearlos también es una característica útil.
Transformación dinámica de etiquetas
Uno de los propósitos de un VNA es almacenar información y servirla a múltiples sistemas que pueden tener diferentes requisitos para su uso y expectativas de 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 promociona como una solución al problema de dos sistemas diferentes que esperan valores diferentes en el mismo atributo. "Tag morphing" se refiere a cambiar los valores en uno o más atributos (generalmente elementos de datos DICOM en este contexto). Esto puede hacerse "estáticamente", en cuyo caso sólo se realiza un mapeo, o "dinámicamente", en cuyo caso se realizan mapeos múltiples, cada uno específico para un destinatario particular.
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 en primer lugar, y los esfuerzos de los proveedores de modalidades y PACS para usarlos "correctamente". Dicho esto, existe una variación en la base instalada e incluso nuevos productos en la forma en que se utilizan algunos campos, en particular para formas de imágenes avanzadas y muy específicas, y la correspondiente variación en lo que las aplicaciones de visualización y análisis avanzados esperan en su entrada. En consecuencia, esta es una característica popular, a pesar de sus peligros. Algunos argumentarán firmemente que es una característica esencial para ser clasificado como VNA.
Esta característica recuerda a lo que es común en el mundo de la versión 2 de HL7 , el denominado motor de interfaz, que está diseñado para mapear prácticamente cualquier cosa con cualquier otra cosa, según la fuente y el destino.
Un caso de uso típico es cambiar los valores en la descripción de la serie proporcionados por las modalidades de adquisición, para permitir que dos PACS diferentes que comparten los mismos datos utilicen diferentes reglas de protocolo de suspensión basadas en la descripción de la serie. Podría decirse que esto podría lograrse de una manera más estándar si las modalidades poblaran otros atributos con más detalle, los protocolos de adquisición y los códigos para ellos estuvieran mejor estandarizados y los motores de protocolo colgante fueran más flexibles, pero dadas las limitaciones del estado de la técnica, esta técnica sigue siendo útil.
La transformación dinámica de etiquetas es distinta de los cambios de atributos específicos relacionados con la resolución de código e identidad entre dominios (a lo que DICOM en PS 3.4 se refiere como "coerción"), para los cuales existen estándares definidos sobre qué cambiar, cuándo y cómo, y cuáles a menudo involucran actores adicionales, como un índice maestro de pacientes, aunque algunos proponentes los agrupan y algunos productos los implementan utilizando el mismo mecanismo.
Michael Gray fue uno de los primeros en proponer la transformación de etiquetas y lo considera una característica esencial de VNA. [22] Se puede encontrar una descripción de los casos de uso de la transformación de etiquetas en el documento técnico de 2010 de Wayne Dejarnette. [23]
Gestión del ciclo de vida de la información
El disco es barato, aunque la energía y el aire acondicionado no lo son, pero a pesar de todo, el almacenamiento tiene un costo finito, particularmente cuando se paga sobre la marcha en lugar de utilizar una infraestructura capitalizada alojada localmente.
En consecuencia, cuando expiran los períodos de retención médico-legal, o expira la utilidad clínica (como en la muerte de un paciente), a muchos usuarios les gustaría poder purgar su almacenamiento. Las reglas para esto son complejas y varían entre jurisdicciones y según la política local. Dadas las demandas conflictivas de los financieros, los gestores de riesgos, los litigantes, los investigadores y los educadores, llegar a un acuerdo sobre una política de este tipo puede resultar difícil.
Independientemente, una característica de VNA potencialmente útil es la compatibilidad con criterios de depuración (eliminación) basados en reglas que se pueden personalizar localmente, ya sea implementando las reglas directamente o respondiendo a las solicitudes de IHE Imaging Object Change Management (IOCM) desde un motor de reglas separado.
Contenido no DICOM
Los VNA no deberían tener dificultades para almacenar contenido DICOM, tales imágenes e información asociada, como estados de presentación y los llamados "documentos de evidencia", como informes estructurados DICOM que contienen elementos tales como mediciones registradas por la modalidad o resultados de posprocesamiento, como los de CAD. .
En un entorno clínico, sin embargo, pueden estar disponibles otros tipos de documentos y objetos a granel que sería deseable almacenar. La mayoría de los 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 metadatos suficientes para identificarlo y administrarlo, como si fuera una imagen. Los VNA deben admitir este tipo de objetos DICOM encapsulados y el "encabezado" DICOM proporciona un medio para obtener los metadatos para la indexación para admitir consultas y recuperación. Michael Gray elabora en detalle este tema en su libro blanco sobre el tema. [24]
Para otros tipos de objetos, o cuando no hay ningún objeto de encapsulación DICOM disponible, o cuando no hay necesidad de interactuar con los sistemas DICOM, siempre que exista un medio estándar de proporcionar los metadatos necesarios para la indexación, como por ejemplo, mediante el uso de HL7 versión 2 mensajes o servicios de registro XDS, entonces, en teoría, un VNA podría almacenar cualquier cosa.
Los tipos específicos de contenido que no es DICOM, como una instancia de documento CDA HL7 que contiene, por ejemplo, un informe de radiología, se pueden almacenar como XDS o encapsular primero en un objeto CDA encapsulado DICOM y almacenarse mediante servicios DICOM o su contenido. y el encabezado podría transcodificarse en una instancia de informe estructurado DICOM. Un VNA con todas las funciones puede tener la capacidad de transcodificar cualquier instancia individual en otra forma dependiendo de lo que necesite el sistema solicitante ("objeto morphing", por así decirlo).
En su informe técnico de 2009 se describe una descripción del enfoque de Wayne Dejarnette para el almacenamiento de objetos que no son DICOM en su producto. [25]
Estandarización de la interfaz
Formato de archivo de imagen en medios de almacenamiento a largo plazo
Existe un acuerdo general en que se requiere el uso del formato de archivo DICOM para las imágenes, y que cuando las imágenes se comprimen para su archivo o transporte, es necesario utilizar esquemas de compresión estándar, no patentados (sintaxis de transferencia). De hecho, una característica distintiva de la mayoría de los VNA en comparación con muchos PACS tradicionales es que se evitan los formatos internos patentados que se utilizaron ostensiblemente en el pasado por razones de "rendimiento", al tiempo que se obtienen un buen rendimiento en todas las interfaces.
Las implementaciones pueden variar en la gama de esquemas de compresión admitidos, ya sea que la compresión reversible (sin pérdidas) sea obligatoria o no para fines de archivo médico-legal. Las implementaciones también varían en la gama de tipos de imágenes específicas de la modalidad que admiten; Aunque muchos archivos admitirán todos los objetos de información de imágenes DICOM en principio, es posible que algunos casos extremos, como imágenes de patología de diapositivas completas y videos largos, no sean 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 sea de la modalidad de adquisición o agregados por otras aplicaciones intermedias (como estaciones de trabajo QC o PACS).
DICOM describe muchas "Definiciones de objetos de información" y "Clases SOP" diferentes para el almacenamiento de imágenes con metadatos específicos relacionados con modalidades y aplicaciones particulares, y la lista de estos crece 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 VNA debería poder almacenar cualquier objeto de imagen DICOM, independientemente de si la clase SOP es reconocida o nueva. Esto se puede lograr mediante el uso de una configuración modificable en el campo para agregar nuevas clases SOP, o mediante el análisis del contenido del "encabezado" de los objetos, o mediante el simple enfoque de aceptar, almacenar y regurgitar cualquier cosa transferida a través de un DICOM C- Funcionamiento ALMACENAMIENTO.
Protocolos de transferencia de imágenes
DICOM convencional
El soporte de los DICOM C-STORE, C-FIND, C-MOVE y preferiblemente C-GET básicos son fundamentales y no debatidos. Las sintaxis de transferencia básicas sin comprimir, que incluyen little-endian de realidad virtual implícita y explícita, y la sintaxis de transferencia de big-endian, menos común, suelen ser compatibles. El rango de sintaxis de transferencia comprimida generalmente incluye JPEG sin pérdida y JPEG 2000 reversible e irreversible , ocasionalmente JPEG-LS , y generalmente JPEG con pérdida para imágenes que se suministraron de esa manera (especialmente fotografías en color verdadero. ) es menos común, pero quizás más común en VNA que en PACS , especialmente para almacenamiento y regurgitación sin visualización.
WADO
La mayoría estaría de acuerdo en que una interfaz VNA importante es la versión original de Web Access to DICOM Persistent Objects (WADO), que permite recuperar imágenes individuales con una URL HTTP en formato de archivo DICOM o prerrepresentar en un formato de consumidor como JPEG .
XDS-Ib
Las transacciones basadas en el servicio web SOAP de IHE Cross Enterprise Document Sharing for Imaging también se consideran generalmente un requisito previo para que una afirmación sea un VNA.
Estados de presentación
La transformación de reproducción de color o escala de grises aplicada a las imágenes para su visualización debe almacenarse como un objeto de estado de presentación DICOM. Estos objetos admiten imágenes en escala de grises y en color verdadero, así como la aplicación de una tabla de búsqueda de pseudo-color a imágenes en escala de grises. Los estados de presentación también pueden registrar cualquier zoom y panorámica (selección del área mostrada) aplicada. IHE los utiliza en el perfil de presentación coherente de imágenes (CPI)
Dado que muchos PACS modernos también pueden almacenar anotaciones de imágenes utilizando objetos de estado de presentación DICOM, un VNA debe admitirlos, incluido no solo el almacenamiento y regurgitación, sino también la selección y visualización en cualquier visor suministrado como un componente de VNA.
Anotaciones, regiones de interés y medidas
El formato preferido para el almacenamiento de anotaciones , regiones de interés y mediciones es el objeto Informe estructurado (SR) DICOM, que permite conservar la estructura, la información codificada y semántica, en lugar de una simple presentación. IHE se refiere a estos como documentos de prueba (ED). Los objetos DICOM SR también pueden producirse en el contexto de IHE, los especifica en el perfil de informe numérico y de imagen simple (SINR).
Dado que muchas modalidades de adquisición, sistemas CAD de mamografía y estaciones de trabajo de análisis cuantitativo de imágenes producen objetos SR, un VNA debería ser capaz de almacenarlos y regurgitarlos. Idealmente, cualquier componente del visor debería ser capaz de una representación genérica (si no ideal) del contenido de cualquier SR, incluida la visualización de coordenadas en imágenes referenciadas.
Para dominios específicos, como Radioterapia , se utiliza un formato más antiguo, el DICOM RT Structure Set, que puede codificar isocontornos de coordenadas relativas del paciente en 3D (solo), y algunas estaciones de trabajo que no son RT también los producen en lugar de SR. Un VNA también debe admitirlos.
Imágenes clave y selección de objetos
Un concepto común en un PACS es que el usuario (como un operador de modalidad o un radiólogo intérprete) marque algunas imágenes (u otros objetos) como "clave", es decir, de interés particular por alguna razón. Aunque los PACS obsoletos solo pueden registrar esto como una bandera en una base de datos interna, los PACS modernos utilizan el objeto de selección de objetos clave DICOM (una forma especializada de SR) para exportar esta información. Este uso se describe en el perfil IHE Key Image Note (KIN). Un VNA debe admitir el almacenamiento y regurgitación de objetos KOS, así como la selección y visualización de estos en cualquier visor.
Informes de dosis de radiación
Dado que muchas técnicas de imágenes médicas suministran cantidades no triviales de radiación ionizante al paciente, es necesario realizar un seguimiento de la exposición a la dosis y, en algunas jurisdicciones, esto debe registrarse por ley. DICOM define una forma especializada de Informe estructurado, el Informe estructurado de dosis de radiación (RDSR) para codificarlo. IHE los utiliza en el perfil de Gestión de la exposición a la radiación (REM). Un VNA debe admitir el almacenamiento y regurgitación de estos, e idealmente, podría extraer información crítica para mostrarla en cualquier visor.
Informes de procedimiento
En las aplicaciones de radiología y medicina nuclear, la práctica de dictar y transcribir (o utilizar el reconocimiento de voz ) está bien arraigada y el resultado de estos suele ser prosa no estructurada o mínimamente estructurada, codificada como texto sin formato y distribuida por fax o mensajes HL7 versión 2 o algunos igualmente primitivo mecanismo. La forma persistente de estos "documentos" no está bien estandarizada, pero muchos clientes esperan que un VNA pueda aceptarlos en el formato local que prefieran. Se aplican los mismos principios que para el almacenamiento de cualquier contenido que no sea DICOM, incluido el uso de mensajes HL7 versión 2 o XDS para proporcionar metadatos en lugar de un "encabezado" estructurado, como en el caso de los informes presentados como PDF, cuando no se han encapsulado en objetos DICOM o CDA. Ahora que HL7 ha prometido relajar su política de IP previamente cerrada, incluida la oferta de CDA gratis para su uso, es posible que CDA se convierta en la forma preferida de codificación, pero los VNA aún deberán aceptar (y posiblemente transcodificar) informes en una plétora de forma desde la base instalada. DICOM define plantillas para la codificación de informes generados por humanos como objetos DICOM Structured Report (SR), e IHE los especifica en el perfil Simple Image and Numeric Report (SINR).
Objetos de radioterapia
Además de los conjuntos de estructuras DICOM RT, para que un VNA se pueda utilizar en una empresa que realiza radioterapia, es necesario almacenar y regurgitar toda la familia de objetos DICOM RT para haz, iones y braquiterapia .
Objetos de datos sin procesar
DICOM define un objeto de datos brutos que es esencialmente un encabezado de instancia compuesta DICOM convencional con información de paciente, estudio, serie e instancia, pero sin carga útil. Estaba destinado al almacenamiento de datos sin procesar que no se representan fácilmente como una imagen o un objeto similar a una imagen, como las vistas sin procesar obtenidas de los detectores de un escáner de TC o los datos del espacio k de un escáner de resonancia magnética, pero se puede utilizar para codificar cualquier cosa. Un VNA debe poder almacenarlos y regurgitarlos, aunque no tenga conocimiento de su contenido y solo el dispositivo que los originó puede ser capaz de interpretarlos.
Objetos de audio, forma de onda y espectroscopia
Aunque hay muchos formatos de consumo para codificar audio de uso generalizado, estos carecen del encabezado o metadatos necesarios para identificar al paciente y al encuentro. Un VNA que quiera respaldar estos debe tener un medio para proporcionar dicha información, como el envío mediante XDS. DICOM define un objeto de audio básico y, aunque no admite la gran cantidad de códecs de audio disponibles en el mundo del consumidor, algunos PACS los producen, por lo que un VNA debería admitirlos.
Las formas de onda basadas en el tiempo (como los ECG) se pueden almacenar como DICOM o en una multitud de otros formatos, y se aplican los mismos principios que para el audio; es decir, si el formato es de orientación médica, use los metadatos del encabezado para indexar durante la ingestión, si no, use XDS para registrarlo.
Se define un objeto de espectroscopia de RM DICOM y, dado que algunas modalidades lo producen, un VNA debería poder almacenar y regurgitar instancias de él.
Objetos privados
DICOM permite el concepto de Clases SOP Privadas, que utilizan los mecanismos de codificación y transferencia DICOM pero cuyo contenido es opaco. Los proveedores los utilizan con buenos resultados cuando es necesario para codificar información que no ha sido estandarizada, y también abusan de ellos por conveniencia en lugar de usar una codificación estándar. Independientemente, dado que su contenido puede ser importante para el flujo de trabajo clínico, una VNA debe ser configurable para aceptarlos, almacenarlos y regurgitarlos.
Casos de uso
- Servicio de imágenes en el sitio a múltiples PACS
- Servicio externo de imágenes a múltiples PACS
- Visualización directa de imágenes (local o externamente)
- Alta disponibilidad
- Continuidad comercial y recuperación ante desastres
Espectro de ofertas de proveedores
Dada la intrincada historia, no debería sorprender que dos productos que afirman ser VNA tengan conjuntos de características y rendimiento completamente diferentes. Sin embargo, existen esencialmente cuatro categorías de productos:
- Sistemas de terceros que se han desarrollado independientemente de PACS
- Sistemas de archivo externos originalmente diseñados para BC / DR
- Productos de repositorio central que admiten el acceso externo y entre empresas
- PACS tradicionales que han mejorado el acceso estándar a su archivo interno
La herencia de cualquier línea de productos individual puede ser un factor importante cuando se considera la idoneidad para una aplicación diferente a la que se pretendía originalmente, a pesar del conjunto de características supuestamente rediseñadas por un departamento de marketing creativo.
Mercado
El tamaño del mercado mundial de VNA es pequeño en relación con el mercado de PACS, pero se supone que está creciendo. [26]
En este resumen se puede encontrar una descripción general del estado del mercado de VNA a fines de 2012. [27]
Referencias
- ↑ Minnie, tía (16 de enero de 2012). "Archivo neutral del proveedor (migración)" . Consultado el 18 de diciembre de 2012 .
- ^ Gray, Michael (11 de diciembre de 2009). "¿Es un archivo neutral de PACS o un archivo neutral del proveedor?" . Consultado el 18 de diciembre de 2012 .
- ^ Haney, MJ (1982). "Sobre estándares para el almacenamiento de imágenes y datos". Serie de conferencias de la Sociedad de Ingenieros de Instrumentación Fotoóptica (Spie) . 318 : 294. Código bibliográfico : 1982SPIE..318..294H . doi : 10.1117 / 12.967664 .
- ^ "PS300-85 ACR-NEMA Digital Imaging and Communication Standard" (PDF) . 1985. Cite journal requiere
|journal=
( ayuda ) - ^ Oosterwijk, H (1986). Dwyer Iii, Samuel J; Schneider, Roger H (eds.). "Implicaciones prácticas y estratégicas de los estándares de interfaz ACR-NEMA". Serie de conferencias de la Sociedad de Ingenieros de Instrumentación Fotoóptica (Spie) . Aplicación de la Instrumentación Óptica en Medicina XIV y Sistemas de Comunicación y Archivo de Imágenes. 0626 : 515. Bibcode : 1986SPIE..626..515O . doi : 10.1117 / 12.975436 .
- ^ Moore, SM (1994). "Shareware DICOM: una implementación pública del estándar DICOM". Medical Imaging 1994: Pacs: Diseño y Evaluación . 2165 : 772. Código Bibliográfico : 1994SPIE.2165..772M . doi : 10.1117 / 12.174371 .
- ^ Gehring, DG (1991). "Descripción detallada de Mayo / IBM PACS". Medical Imaging V: Diseño y Evaluación de Pacs . 1446 : 248. Código Bibliográfico : 1991SPIE.1446..248G . doi : 10.1117 / 12.45280 .
- ^ Erickson, Bradley (1998). "La evolución de la imagen electrónica en el entorno médico" . Imaging Digit J . 11 (Supl. 1): 71–74. doi : 10.1007 / BF03168264 . PMC 3453350 . PMID 9735437 .
- ^ "Teramedica, Inc" .
- ^ Gray, Michael (5 de junio de 2007). "Archivo empresarial neutral PACS: ¿quién lo creará?" . Consultado el 18 de diciembre de 2012 .
- ^ Daher, Nadim (18 de octubre de 2006). "Middleware de gestión de archivos PACS empresarial: ¿quién es quién?" . Consultado el 18 de diciembre de 2012 .
- ^ Minnie, tía (19 de julio de 2007). "RE: Leyes de PACS del Dalai" . Consultado el 18 de diciembre de 2012 .
- ^ Dejarnette, Wayne (17 de septiembre de 2009). "¿Qué es un archivo de proveedor neutral?" (PDF) . Consultado el 18 de diciembre de 2012 .
- ^ Dejarnette (10 de septiembre de 2013). "¿Qué es un archivo de proveedor neutral?" . Consultado el 10 de julio de 2014 .
- ^ Gray, Michael (15 de diciembre de 2009). "Ingredientes esenciales de un archivo neutral PACS" . Consultado el 18 de diciembre de 2012 .
- ^ Werb, Shannon (31 de octubre de 2012). "12 atributos de un archivo neutral de proveedor verdadero" . Consultado el 18 de diciembre de 2012 .
- ^ Oosterwijk, Herman (5 de julio de 2010). "¿Qué es un VNA de todos modos?" (PDF) . Consultado el 22 de abril de 2014 .
- ^ Gray, Michael (23 de noviembre de 2010). "Infraestructura de nube en configuraciones de archivo neutrales del proveedor" (PDF) . Consultado el 18 de diciembre de 2012 .
- ^ Gray, Michael (27 de enero de 2012). "Cómo romper la barrera de entrada VNA" (PDF) . Consultado el 10 de julio de 2014 .
- ^ Marion, Joseph (27 de agosto de 2013). "Un marco para ayudar a la implementación de VNA" . Consultado el 10 de julio de 2014 .
- ^ Wilson, Dave (8 de febrero de 2011). "Los 5 mitos principales sobre los archivos neutrales del proveedor" . Consultado el 10 de julio de 2014 .
- ^ Gray, Michael (18 de junio de 2007). "Transformación de etiquetas DICOM - ingrediente esencial en el archivo PACS empresarial" . Consultado el 18 de diciembre de 2012 .
- ^ Dejarnette, Wayne (4 de enero de 2010). "Gestión de contexto y transformación de etiquetas en el mundo real" (PDF) . Consultado el 18 de diciembre de 2012 .
- ^ Gray, Michael (18 de octubre de 2010). "Estrategia de mejores prácticas para tratar con objetos de datos que no son DICOM en un archivo neutral PACS" (PDF) . Consultado el 18 de diciembre de 2012 .
- ^ Dejarnette, Wayne (11 de agosto de 2009). "Archivado de datos no DICOM con xDL" (PDF) . Consultado el 18 de diciembre de 2012 .
- ^ Noticias de tecnología de imágenes (14 de octubre de 2013). "VNA, mercado PACS por valor de $ 3.48 mil millones en 2018" . Consultado el 21 de diciembre de 2015 .
- ^ Ahadome, Theo (14 de diciembre de 2012). "La competencia se intensifica en el mercado de archivos neutrales del proveedor" . Consultado el 21 de diciembre de 2015 .