Imágenes de ultrasonido enviadas con éxito: ¿ha aceptado la responsabilidad el archivo?

¿Qué garantiza realmente una respuesta C-STORE exitosa?

Un sistema de ultrasonido indica «Enviado con éxito». Antes de reemplazar una unidad o recargar el sistema operativo, un ingeniero de servicio debe saber si eso significa que todos los registros requeridos están protegidos en otro lugar. La primera tarea consiste en identificar el destino y los objetos individuales detrás del estado. El icono de resumen de una consola puede representar un trabajo, una serie o un examen; su significado proviene de la documentación de ese producto.

DICOM (Digital Imaging and Communications in Medicine) define Clases de Servicio independientes de Almacenamiento (Storage) y Compromiso de Almacenamiento (Storage Commitment). El éxito de C-STORE es una respuesta de almacenamiento a nivel de aplicación, no meramente un acuse de recibo de entrega TCP. PS3.4 B.1.2 define la finalización exitosa como el almacenamiento de la información en algún medio con acceso durante un período; el método de acceso y la duración del almacenamiento dependen de la implementación y de su declaración de conformidad. No se sobreentiende la compatibilidad con Query/Retrieve. ¹³ El Anexo J explica que la Clase de Servicio de Almacenamiento no establece por sí misma un compromiso explícito de custodia. No convierta esa distinción en una afirmación de que C-STORE no impone requisitos, o de que todo receptor utiliza una memoria caché volátil. El comportamiento de almacenamiento y los niveles de almacenamiento admitidos también tienen requisitos de conformidad. ^{1 12}

Un receptor puede persistir una instancia antes de acusar recibo de ella. Eso puede ser una evidencia útil, particularmente cuando su declaración de conformidad describe dicho comportamiento. La cuestión pendiente es qué puede establecer el emisor sobre la retención y la recuperación posterior. Una respuesta de éxito de un gateway también debe distinguirse de la evidencia sobre el archivo posterior. Identifique la AE —la entidad de aplicación DICOM— que realmente aceptó la operación.

• Destino: ¿La operación fue aceptada por el PACS/VNA final, un router o un receptor temporal? PACS significa sistema de archivo y comunicación de imágenes (picture archiving and communication system); VNA significa archivo neutro al proveedor (vendor-neutral archive).
• Cobertura: ¿Qué instancias SOP (Service-Object Pair) se enviaron? Un SOP Instance UID —un identificador único— identifica un objeto DICOM; un clip multifotograma no se cuenta una vez por fotograma.
• Excepciones: ¿Quedó alguna instancia pendiente, rechazada o aceptada con advertencias? Conserve las respuestas reales en lugar de deducir la completitud a partir de una etiqueta a nivel de estudio.
• Siguiente evidencia: ¿Existe un resultado de compromiso, un acuerdo de retención alternativo documentado o únicamente un registro de envío? Estos son registros diferentes.

Una sola operación exitosa tampoco establece el buen estado continuo de la red o del hardware. Cuando el problema sea una falla de envío, utilice la guía independiente sobre el aislamiento de fallas de salida DICOM y PACS en ultrasonido. Este artículo parte de un envío aparentemente exitoso y examina la evidencia que aún falta.

¿Qué es el compromiso de almacenamiento —y qué promete el archivo?

Según el Anexo J, el SCU (Service Class User) de compromiso de almacenamiento solicita la custodia al SCP (Service Class Provider) de compromiso de almacenamiento. Estos roles describen un servicio específico, no una identidad general de cliente/servidor para cada operación en un equipo. La declaración de conformidad del SCP explica la duración, las capacidades de recuperación, la latencia y la capacidad. Puede prometer un almacenamiento limitado en lugar de un archivo permanente. La ubicación de recuperación también puede diferir de la AE que aceptó el compromiso. ¹

Para el modelo Push de DIMSE (DICOM Message Service Element), SOP Class UID 1.2.840.10008.1.20.1, la solicitud N-ACTION incluye un Transaction UID (0008,1195) y una Referenced SOP Sequence (0008,1199). Cada entrada identifica una clase SOP y una instancia SOP. Una respuesta N-ACTION exitosa establece la recepción de la solicitud; el resultado posterior establece su desenlace. La solicitud puede contener un solo objeto o un conjunto, por lo que una solicitud aceptada no es prueba de que se haya incluido el estudio completo. ²

El resultado de N-EVENT-REPORT incluye el Transaction UID coincidente. El tipo de evento 1 reporta éxito para todas las instancias solicitadas. El tipo de evento 2 reporta que existen fallas e identifica tanto las instancias exitosas como las fallidas, con un motivo para cada falla. Debe darse cuenta de la totalidad del conjunto solicitado. Un acuse de recibo del N-EVENT-REPORT es otra respuesta más: no confunda su estado de éxito con el resultado contenido en el evento. ³

Las instancias comprometidas deben almacenarse en el nivel de almacenamiento 2 (Full), incluidos los atributos privados. El Anexo J también exige los datos de píxeles completos en lugar de solo un enlace a ellos. Estos requisitos no prescriben RAID, un algoritmo de suma de verificación, una secuencia de confirmación de base de datos ni un medio de almacenamiento en particular. El nivel de almacenamiento 2 no es una afirmación universal de preservación bit a bit; la Clase de Servicio de Almacenamiento también describe el tratamiento permitido de los atributos. ¹² Un evento positivo es el compromiso declarado por el SCP; no es una auditoría independiente de la implementación del archivo ni de las disposiciones de recuperación ante desastres. ^{1 3}

El compromiso de almacenamiento no decide por sí mismo la custodia legal, la propiedad, los periodos de retención impuestos a la institución ni la autorización para purgar los medios locales. DICOM deja el comportamiento de eliminación del SCU fuera de la definición del servicio y exige que dicho comportamiento esté documentado. Las políticas de la institución, los contratos y las obligaciones aplicables siguen siendo decisiones independientes. La referencia de SIIM recomienda el servicio como un complemento a la transferencia, pero esa recomendación no proporciona una política de retención para la institución. ^{1 9}

Una matriz de evidencia para la decisión de retención local

Utilice esta matriz para etiquetar la evidencia disponible en un registro de servicio. La columna de acción es un límite de revisión propuesto para la institución, no un comando de eliminación ni un flujo de trabajo exigido por DICOM. Una falla, una respuesta pendiente o un inventario de origen incompleto deben permanecer visibles en lugar de comprimirse en un único estado verde.

Considere un caso sintético de aceptación con seis objetos: dos imágenes fijas, tres clips multifotograma y un informe estructurado. Una solicitud que cubra los cinco objetos de imagen puede recibir el tipo de evento 1 mientras que el informe nunca fue solicitado. Una etiqueta de “comprometido” a nivel de estudio sobreestimaría entonces la evidencia disponible. El objeto faltante debe conciliarse con el inventario de origen; verificar repetidamente la misma transacción exitosa no ampliará su alcance.

En un segundo caso sintético, la solicitud incluye los seis objetos, pero el resultado enumera cinco éxitos y un fallo. Se trata de un resultado parcial, no de un estudio confirmado por completo. Registre qué objeto falló y su motivo. Conserve el origen mientras el personal calificado resuelve la excepción. Estos ejemplos ilustran la conciliación de conjuntos; no son casos de pacientes ni tasas de fallo medidas.

¿A dónde llega el resultado y por qué podría faltar?

La norma exige la capacidad para la entrega de N-EVENT-REPORT en una asociación diferente a la de N-ACTION; también permite un intento en la misma asociación. Por lo tanto, una regla universal de que “siempre se requieren tres conexiones” es inexacta. Orthanc documenta una implementación de tres asociaciones, y la declaración de Lumify R5.0 documenta el manejo asíncrono de resultados. Consulte las declaraciones de conformidad de ambos pares antes de interpretar una devolución de llamada faltante. ^{3 5 10}

1. ¿Se envió una solicitud? Separe el éxito de C-STORE de la aceptación de N-ACTION. Confirme el destino de confirmación correcto, la SOP Class admitida y los permisos en lugar de asumir que la transferencia de imágenes habilita la confirmación.
2. ¿Se aceptó la solicitud? Mantenga diferenciada una operación fallida de una solicitud aceptada que espera su resultado. Registre el Transaction UID para correlacionar ambos registros.
3. ¿Se generó un resultado? Solicite al propietario del archivo que identifique el resultado y el conjunto de instancias solicitado. El procesamiento del servidor o un fallo por instancia pueden explicar el resultado sin que exista un fallo de red.
4. ¿Pudo el resultado llegar al remitente? Cuando se utilice una asociación independiente, el personal calificado de TI/PACS debe comparar los AE titles configurados, la dirección, el puerto de escucha, la política de red aprobada y la disponibilidad del dispositivo.
5. ¿Se registró el resultado? Compare el estado del remitente con el registro del archivo. El comportamiento de tiempo de espera, reintentos y persistencia del estado específico de cada producto es importante; no asuma que todos los productos retienen o reintentan las transacciones pendientes de forma idéntica.

Aceptar una asociación no cambia automáticamente la función de servicio de Storage Commitment de una modalidad a SCP. El archivo sigue siendo el SCP de Storage Commitment cuando inicia la asociación para el resultado, con la negociación de funciones según se describe en J.3.3. Esto es importante al leer tablas de conformidad que enumeran la modalidad como SCU a pesar de que escuche resultados entrantes. ³

Una regla de firewall, una dirección de dispositivo modificada o un carro desconectado pueden interferir con una devolución de llamada, pero esta guía no dispone de un conjunto de datos que demuestre qué causa es la más común. Los resultados faltantes no demuestran que los estudios se hayan perdido, y los envíos exitosos no demuestran que la ruta de devolución de llamada funcione. Mantenga protegidas las copias requeridas e investigue junto con el propietario del archivo; no eluda los controles de red ni infiera la necesidad de una placa de repuesto únicamente a partir de este síntoma.

¿Qué establecen los documentos de ultrasonido citados?

Los siguientes ejemplos establecen un comportamiento documentado específico. No constituyen una matriz de compatibilidad, un estudio completo de OEM ni una prueba de que otra versión cuente con la misma función. Obtenga el documento correspondiente al software instalado y al archivo receptor antes de tomar una decisión de aceptación.

La declaración histórica de LOGIQ7 hace que la interpretación de la cola sea especialmente importante: en la Rev 4.0, una solicitud de compromiso no respondida se elimina después de dos días sin advertir al usuario. Un resultado exitoso también elimina la solicitud. Por lo tanto, una cola vacía no permite distinguir dichos resultados en esa revisión; conserve el resultado de la transacción y el inventario de origen en lugar de considerar la desaparición de un trabajo como prueba de compromiso. No debe asumirse este comportamiento para otros modelos o versiones. ⁴

La declaración de Lumify ofrece un recordatorio útil de que el comportamiento de reintento es específico de cada producto: describe reintentar tras 96 horas sin la respuesta esperada y reenviar las instancias fallidas en la secuencia indicada. Se trata de una descripción de implementación, no de un período de espera recomendado para todos los ecógrafos ni de una autorización para descartar estudios pendientes. Utilice el comportamiento propio de la versión instalada al definir un intervalo de escalamiento. ⁵

La guía del PX distingue tres opciones de selección de estudios y advierte que la elección debe coincidir con la configuración DICOM. Con un servidor de compromiso de almacenamiento configurado, indica eliminar únicamente los estudios comprometidos. También describe una configuración de solo archivo que puede utilizar el estado de estudio archivado. Esta última opción no convierte C-STORE en compromiso de almacenamiento: la institución aún necesita evaluar su esquema de archivo y su política de registros. Esta guía no indica a un administrador que habilite ninguna de las dos opciones. ⁶

¿Qué debe establecer la institución antes de modificar la retención local?

Trate la presión de almacenamiento y la autorización de retención como tareas independientes. Una advertencia de espacio en disco puede reflejar la carga de trabajo, un envío fallido, la falta de resultados de compromiso, problemas de almacenamiento o la configuración de políticas. No determina qué registros pueden descartarse. Mantenga protegidos los registros no resueltos y utilice el proceso de escalamiento de la institución cuando la capacidad amenace el flujo de trabajo.

1. Designe al responsable directo. Ingeniería clínica puede recopilar la evidencia, pero los responsables de archivos y registros de la institución deben aprobar el esquema de retención. Registre quién acepta las excepciones no resueltas y quién puede autorizar un cambio de configuración.
2. Concilie el conjunto completo de objetos. Compare el inventario de origen con la solicitud y el resultado, incluidos los informes y clips requeridos. Conserve las instancias fallidas u omitidas; una imagen o serie exitosa no constituye prueba de un examen completo.
3. Lea los términos de compromiso del archivo. Identifique la AE responsable, la duración de retención, la ubicación y latencia de recuperación, los límites de capacidad y los acuerdos de servicio pertinentes. Un compromiso de duración limitada debe ajustarse al plan de registros a más largo plazo de la institución. ¹
4. Determine la retención local según las políticas. No existe un período de gracia universal establecido por estas fuentes. Las antigüedades seleccionables de la guía del PX son opciones del producto, no evidencia de que 72 horas o siete días sean seguros para una institución en particular. ⁶
5. Realice pruebas con datos aprobados que no correspondan a pacientes. Antes de la liberación, demuestre los estados esperados de envío, solicitud, resultado y excepción conforme al procedimiento del OEM. Registre los ajustes revisados y la aprobación del centro; no pruebe el comportamiento de eliminación en la única copia de un registro clínico.

La retención local de rutina también es diferente del saneamiento antes de que el equipo salga de un centro. Proteger el archivo no demuestra que una unidad de disco haya sido saneada. Para esa decisión independiente, utilice la guía de exportación, preservación y borrado de datos de pacientes y acuerde el plan de manipulación de datos antes de un envío para reparación.

¿Qué sucede si el archivo no admite storage commitment?

La falta del rol de SCP de Storage Commitment no determina que un archivo sea inseguro. Por el contrario, una etiqueta de producto que indique “compatible con DICOM” no demuestra que admita este servicio. Solicite la declaración de conformidad real y el acuerdo de retención documentado del centro. Si no existe una alternativa aprobada y adecuada, preserve los registros locales requeridos y escale el caso en lugar de inventar una equivalencia.

La consulta y recuperación independiente puede aportar evidencia de disponibilidad para una alternativa aprobada por el centro. Utilice un cliente de archivo autorizado y confirme que esté leyendo el destino en lugar de la memoria caché local del escáner. Una estación de trabajo independiente es una forma útil de reducir esa ambigüedad; no es un requisito universal especificado por el Anexo J. Cualquier verificación de datos de pacientes debe permanecer dentro del entorno autorizado del centro.

• Identidad: Coteje los identificadores pertinentes de estudio, serie, SOP Class y SOP Instance con el inventario de origen. Los recuentos por sí solos pueden ocultar un objeto faltante y uno adicional inesperado.
• Exhaustividad: Verifique cada imagen fija, clip multifotograma e informe requerido. Es posible que un visor exclusivo de imágenes no muestre todos los tipos de objetos; recurra al responsable del archivo cuando su inventario no pueda determinar la cobertura.
• Alcance de la recuperación: Registre con precisión qué objetos fueron recuperados y verificados. Una muestra puede demostrar una vía en funcionamiento; no puede probar la integridad ni la disponibilidad de todos los objetos no probados.
• Retención: Documente quién conservará los registros, durante cuánto tiempo y cómo se pueden recuperar. Una recuperación exitosa determina la disponibilidad en ese momento, no una promesa futura de almacenamiento.
• Disposición: Mantenga protegidas las copias locales hasta que el responsable del centro acepte la totalidad de las evidencias y cualquier excepción conforme a su política. La recuperación por sí sola no constituye una autorización para la eliminación.

C-FIND y C-MOVE, o los servicios compatibles de consulta y recuperación basados en la web, son mecanismos posibles; la elección adecuada depende de ambos extremos. No asuma que una consulta a nivel de estudio ofrece una exhaustividad a nivel de instancia, ni que una miniatura legible demuestre que el contenido multifotograma original está intacto. Este artículo especifica la cuestión relativa a la evidencia, no comandos para un archivo de producción.

La evidencia de implementación también puede moderar las suposiciones sobre el compromiso en sí. Orthanc documenta que su SCP básico verifica la presencia en la base de datos y la concordancia de SOP Class; se pueden añadir verificaciones personalizadas. La documentación de su SCU también describe informes activos que se mantienen en la memoria RAM y se pierden al reiniciar. Estos son detalles específicos de Orthanc, pero ilustran por qué la designación de un protocolo no sustituye las condiciones reales de almacenamiento del receptor ni el comportamiento de persistencia del emisor. ¹⁰

¿Cómo se relaciona esto con el trabajo en unidades de disco y el retorno al servicio?

Antes de una recarga de almacenamiento o del reemplazo de una unidad, separe la preservación de los estudios requeridos de la restauración del software y la configuración del sistema. La evidencia de archivo no resuelta debe registrarse en la autorización de trabajo antes de realizar trabajos destructivos. Si la consola no inicia, siga la ruta de decisión entre unidad y placa base; no asuma que una unidad averiada no contiene datos recuperables de pacientes.

Después de un cambio de backend, placa base o interfaz de red, el personal calificado debe comparar la configuración de conectividad autorizada antes y después del servicio. Cuando la reparación modifica una dirección, un título de AE, la configuración del adaptador o un listener, una prueba saliente exitosa puede coexistir con un resultado de compromiso faltante. Documente los cambios observados en lugar de asumir que cada reemplazo de placa cambia la identidad de red.

La aceptación debe cubrir los servicios efectivamente configurados para ese dispositivo y archivo, utilizando datos de prueba aprobados que no pertenezcan a pacientes. Registre el conjunto de objetos de origen, las respuestas de envío, la identidad de la solicitud, el resultado y la verificación de destino, según corresponda. Las pruebas de hardware y la aceptación del archivo responden a preguntas diferentes. La guía de evidencia de prueba de placas en equipo real explica los límites del registro de prueba de una placa reparada; no puede certificar las disposiciones de retención del archivo del hospital.

Una transferencia de evidencia útil para un resultado no resuelto

El siguiente registro propuesto ayuda al ingeniero del ecógrafo y al responsable del PACS a investigar la misma transacción. No es un formulario exigido por el OEM. Mantenga los identificadores clínicos, las capturas de paquetes y los detalles de red dentro de los sistemas aprobados de la institución; una consulta de reparación externa normalmente requiere un resumen depurado de síntomas en lugar de estudios de pacientes.

Dónde encaja Rongtao—y dónde no

Rongtao ofrece reparación de placas de ultrasonido y repuestos probados, con servicios de sondas disponibles para la falla correspondiente. El plazo típico de reparación de placas es de 5–8 días hábiles, la prueba en equipo real es de 48 horas y la garantía estándar es habitualmente de 90 días; confirme el producto, servicio y términos aplicables en la cotización. Estos hechos del servicio no establecen una capacidad de integración de PACS ni de validación de archivos. ¹¹

Los equipos de PACS, TI y registros de la institución son los responsables de la configuración del archivo, las aprobaciones de red y las decisiones de retención. Un resultado de compromiso pendiente debe investigarse con dichos equipos antes de comprar hardware. El rol de reparación de Rongtao comienza donde existe evidencia de una falla de hardware reparable; un informe que indique que un examen fue “enviado pero no comprometido” no identifica una placa averiada.

Para una evaluación de hardware mediante servicios de reparación de ultrasonido o contacto, proporcione el OEM, el modelo exacto, el software instalado cuando corresponda, el número de parte del fabricante, el texto del síntoma/error, la cantidad y el país de destino. Incluya fotografías de la etiqueta existente y de ambos lados de la placa cuando estén disponibles a partir de trabajos de servicio calificados; no desmonte el equipo solo para una consulta. Describa si lo que está fallando es C-STORE, N-ACTION o el resultado, utilizando evidencia depurada. No envíe registros de pacientes en el paquete de cotización.

Preguntas frecuentes

El escáner indica que se envió con éxito. ¿Podemos eliminar el estudio?
El estado por sí solo es evidencia insuficiente para esa decisión. Concilie el conjunto de objetos requeridos y el compromiso aplicable o la evidencia alternativa aprobada; luego, siga la política de retención del establecimiento. Esta guía no autoriza la eliminación. ¹

¿Es el compromiso de almacenamiento una garantía permanente o de custodia legal?
Es un compromiso explícito del protocolo cuya naturaleza está definida por la declaración de conformidad de la implementación. La duración puede ser limitada. No resuelve por sí mismo la custodia legal ni prescribe la política de eliminación local del establecimiento. ¹

Nuestra solicitud fue aceptada pero no llegó ningún resultado. ¿Qué debemos verificar?
Correlacione el UID de transacción en ambos pares, determine si el archivo produjo un resultado y verifique la entrega y el registro del emisor conforme a la implementación real. Una devolución de llamada independiente puede fallar incluso cuando la transferencia saliente funciona. Evite asumir una sola causa, un intervalo de reintento fijo o que la falta de un resultado demuestre la pérdida de datos. ^{2 3}

¿Qué nos dicen los motivos de falla?
DICOM PS3.3 C.14.1.1 define la falla de procesamiento 0110H, la instancia SOP no disponible 0112H, la limitación de recursos 0213H, la clase SOP referenciada no admitida 0122H, el conflicto de clase/instancia 0119H y un UID de transacción ya en uso 0131H. Estos significados específicos no identifican un disco averiado, una causa de pérdida de paquetes ni una placa que reemplazar. Conserve el conjunto fallido e investigue con el propietario del archivo. ⁷

¿Un resultado exitoso demuestra que todo el estudio está comprometido?
Solo si la solicitud incluyó todos los objetos requeridos y el resultado da cuenta de ese conjunto. Una transacción exitosa para instancias de imagen no cubre un informe que nunca fue solicitado. Compare identidades, no solo totales. ^{2 3}

¿Cuándo debe volver a verificarse esta evidencia?
Vuelva a verificarla después de cambios en el software del escáner o en la conectividad, migraciones del archivo, modificaciones en los términos de retención o revisiones de la norma citada y de los documentos del OEM. Registre las versiones exactas utilizadas en la aceptación. Los ejemplos históricos de LOGIQ7 y S-Series deben permanecer etiquetados como históricos, aun cuando la revisión de la fuente sea reciente.