¿Por qué un estudio de ultrasonido reenviado aparece duplicado en el PACS?
Una consola de ultrasonido puede mostrar una transferencia no confirmada mientras que el sistema de archivo y comunicación de imágenes (PACS) ya contiene algunos o todos los objetos enviados. Un reintento posterior puede generar recuentos inesperados, una imagen sin cambios o una entrada de estudio con apariencia de duplicado. Dichas observaciones describen problemas diferentes. Registre cuál de ellos ocurrió: dos entradas de estudio, series repetidas, mosaicos de imagen adicionales, un mensaje de error o la ausencia de cambios tras un reenvío exitoso.
Para los equipos hospitalarios de gestión de tecnología sanitaria (HTM), ingeniería clínica y servicios independientes, la decisión inmediata es quién necesita qué evidencia. El proveedor del equipo de ultrasonido investiga la generación en origen; el responsable del archivo investiga la ingesta y la indexación; el responsable clínico del centro decide si los registros requeridos están completos y utilizables. Sin esa separación, un problema de visualización ambiguo puede transformarse en una orden de reparación innecesaria o en una modificación no segura de los registros. Esta guía no estima con qué frecuencia el software o el hardware es el responsable.
Mantenga diferenciados el envío original y el reintento en el registro de incidencias. “Lo enviamos dos veces” no demuestra que ambos intentos contuvieran los mismos objetos. Anote la acción exacta realizada en la consola: un reintento automático, un reintento desde la cola de trabajos, una nueva exportación desde la revisión o una exportación tras agregar contenido. No deduzca el comportamiento de los UID del equipo a partir de la etiqueta del botón. Conserve todas las copias salientes disponibles y los registros correlacionados del receptor antes de que la rotación rutinaria de registros los elimine.
Este artículo aborda la identidad del objeto tras un reenvío. Si el problema es específicamente la recuperación de estudios previos mediante C-MOVE, utilice la guía independiente para rastrear la conexión de recuperación. El envío saliente exitoso de imágenes y una recuperación fallida son rutas diferentes; ninguna por sí sola establece por qué el visor muestra entradas duplicadas.
¿Qué identidad cambió entre el envío original y el reintento?
DICOM (Digital Imaging and Communications in Medicine) utiliza identificadores únicos (UID) para estudios, series e instancias individuales de Service-Object Pair (SOP) en diferentes niveles. Un solo objeto cine multifotograma puede contener muchos fotogramas, por lo que el recuento de fotogramas mostrados no es necesariamente un recuento de instancias. Utilice los siguientes campos para la comparación; no sustituya los UID por nombres de archivo, etiquetas de serie o números de acceso. 1 2 3
- Study Instance UID (0020,000D): identifica el estudio. Accession Number y Study ID son campos separados; la coincidencia de sus valores mostrados no establece que los Study Instance UID sean iguales. 2
- Series Instance UID (0020,000E): identifica la serie dentro del estudio. Series Number (0020,0011) es un atributo separado y no debe utilizarse como sustituto. 3
- SOP Instance UID (0008,0018): identifica el objeto individual. Compare cada objeto requerido de imagen fija, cine o informe en lugar de tratar el estudio como un solo archivo. 1
- SOP Class UID (0008,0016): identifica la clase de objeto. Cuando los valores de clase e instancia están codificados en el conjunto de datos, deben coincidir con sus correspondientes identidades DIMSE y de metadatos del archivo. Una representación contradictoria requiere investigación. 1
Tres flujos de trabajo posibles ilustran por qué la carga útil real es importante. Se trata de casos de investigación, no de afirmaciones sobre cada modelo de ecógrafo o versión de software. La norma define el significado de los identificadores; la declaración de conformidad del ecógrafo instalado y la transacción capturada establecen lo que su función de reenvío realmente hizo.
Reintento en cola: Si la cola retransmite los mismos objetos almacenados, los identificadores deberían coincidir al compararse. Determine esto a partir de la carga útil real del reintento o de los registros disponibles. La ausencia de respuesta en el emisor no demuestra que el receptor haya descartado el primer objeto. Evite calificar los dos archivos como “idénticos bit por bit” a menos que se hayan comparado realmente.
Nueva exportación desde revisión: Compare su conjunto de objetos con el envío inicial. Si aparecen identificadores de estudio, serie o instancia diferentes, consulte al proveedor del ecógrafo si el flujo de trabajo documentado de exportación o corrección los explica. Un nuevo UID es evidencia de una identidad diferente, no una prueba por sí misma de una falla del ecógrafo. Si la atribución del paciente difiere, canalice ese problema a través del proceso de conciliación de la identidad del paciente y del emisor de la institución antes de evaluar la consolidación de registros.
Contenido guardado adicional: Un examen con imágenes agregadas puede contener tanto instancias enviadas previamente como nuevas. Contabilice cada conjunto por separado. No asuma que reabrir un examen deba crear una nueva serie, ni que todo reenvío deba conservar la identidad original del estudio. El comportamiento admitido depende del flujo de trabajo exacto y de la versión.
Utilice la Tabla 1 como registro conjunto de evidencias. Complete explícitamente las celdas no disponibles en lugar de copiar un valor del receptor en la columna de envío original. Un archivo recuperado ahora del PACS es evidencia del estado retenido; no es automáticamente una copia intacta de lo que salió originalmente del escáner. Mantenga los identificadores vinculados al paciente, los detalles de la red y los archivos dentro de los sistemas aprobados de la institución.
| Elemento de evidencia | Envío original | Reintento real | Objeto retenido por el receptor | Diferencia o evidencia faltante | Responsable y siguiente verificación |
|---|---|---|---|---|---|
| Sistema y ruta | Modelo, compilación de software, aplicación remitente y destino | Acción exacta de reenvío, compilación y destino | Producto/versión del receptor y punto de conexión de ingesta | Cualquier cambio de ruta o de versión | Responsables del escáner/PACS: identificar cada intermediario |
| UID de clase SOP y de instancia | (0008,0016) y (0008,0018) en la evidencia saliente | Mismos campos en el reintento real | Mismos campos en la copia recuperada autorizada | Coincidencia exacta, discrepancia o no disponible | Proveedor del PACS/escáner: comparar el conjunto de datos y las identidades disponibles de comando/metadatos de archivo |
| UID de estudio y de serie | (0020,000D) y (0020,000E) | Jerarquía de los objetos reenviados | Jerarquía retenida por el archivo | Agrupación modificada o mapeo documentado | Responsable del PACS: separar la jerarquía de origen de la agrupación del visor |
| Alcance del objeto y del contenido | Imágenes fijas, objetos de cine y objetos de informe requeridos | Objetos repetidos frente a objetos nuevos | Qué objetos son recuperables; qué contenido se verificó | Diferencias en fotogramas, anotaciones o informes; objetos no probados | Responsables clínicos/del PACS: definir la integridad y el alcance de la comparación |
| Hora del evento y procedencia | Hora de envío, desfase y referencia original disponible | Hora del reintento y activador real | Hora de ingesta/recuperación y referencia de la transacción | Incertidumbre del reloj u original faltante | Responsables de TI/del escáner: correlacionar registros sin tratar las marcas de tiempo como identidad |
| Operación y respuesta | Solicitud/respuesta real, o ninguna respuesta observada | Operación real, estado y comentario de error | Evento del receptor correlacionado | Advertencia, falla, tiempo de espera agotado o registro faltante | Responsable del PACS: interpretar el estado específico del servicio; el tiempo de espera agotado no es un código de estado DIMSE |
| Transformaciones | Valores originales donde estén disponibles | Cualquier corrección documentada o exportación derivada | Registro de coerción/conversión y mapeo antes/después | Cambios explicados frente a cambios no explicados | Responsables de integración/del escáner: identificar el sistema transformador |
| Disposición y responsable | Lo que se sabe que entregó el primer envío | Política activa aplicable a esta transacción | Objeto anterior conservado, reemplazado, almacenado adicionalmente o sin resolver | Evidencia documental para esa conclusión | Responsable del PACS: proporcionar la política/versión y la evidencia del objeto retenido |
Fuente: Formulario editorial de evidencias basado en la documentación citada de identidad y Storage; no es un formulario exigido por DICOM.
¿Qué retuvo el archivo después del reenvío?
Las definiciones de identidad de DICOM no establecen la disposición configurada de un objeto repetido en un receptor en particular. Solicite al administrador del PACS el producto/versión, las reglas activas, el registro de transacciones pertinente y una copia autorizada de lo que ahora se puede recuperar. Mantenga el objeto almacenado separado de los metadatos de la base de datos y de la presentación en el visor: un cambio en uno no es prueba de que los tres hayan cambiado.
Dos referencias de implementación principales demuestran la necesidad de esa verificación. Son ejemplos, no una clasificación de PACS, lista de compatibilidad ni instrucción para modificar la configuración de producción. La documentación es pública; no se probó ningún archivo instalado para este artículo.
La documentación descriptiva de Storage de dcm4che Archive 5 documenta varias políticas de manejo de repeticiones. El mismo sitio de documentación describe por separado los controles de discrepancias relacionales en su referencia de configuración de la Entidad de Aplicación (AE) de red del archivo. Considere los nombres de las políticas a continuación como resúmenes de dichos documentos y no como una receta de configuración; confirme la versión implementada y los controles vigentes con su responsable. 8 12
- Separe la política del resultado: registre la configuración aplicable en el momento del evento, no solo la configuración actual. Pregunte si un intermediario aplicó sus propias reglas antes del archivo final.
- Separe el reemplazo de la visualización: pregunte qué objeto se conservó o reemplazó y qué actualizaciones de la base de datos o del visor se produjeron. Una marca de tiempo de ingesta más reciente por sí sola no establece un contenido clínico más reciente.
Orthanc añade otra consideración de identidad: su identificador de instancia es un hash de Patient ID, Study Instance UID, Series Instance UID y SOP Instance UID. The Book describe que se conserva el primer objeto de forma predeterminada cuando ese identificador de Orthanc coincide, con la opción de reemplazo disponible mediante OverwriteInstances. Por lo tanto, comparar únicamente el SOP Instance UID no reproduce la clave de indexación de Orthanc. 9
Si el incidente también plantea una decisión de retención, revise la responsabilidad del archivo antes de cambiar la retención. Ni un mensaje duplicado ni una miniatura sin cambios autorizan la eliminación de la copia local o de un registro del archivo clínico.
| Ejemplo documentado | Condición de coincidencia | Disposición documentada | Lo que aún requiere evidencia |
|---|---|---|---|
| Narrativa de Storage de dcm4che: NEVER | SOP Instance UID igual | Se ignora la repetición entrante; se devuelve éxito | Qué contenido anterior permanece recuperable 8 |
| Narrativa de Storage de dcm4che: ALWAYS | SOP Instance UID igual | La instancia recibida posteriormente reemplaza a la instancia anterior | Controles efectivos, transformaciones y resultado real 8 12 |
| Narrativa de Storage de dcm4che: SAME_SERIES | SOP Instance UID igual; los UID de Study y Series también son iguales | Se sobrescribe cuando la jerarquía coincide; de lo contrario, se almacena adicionalmente | No interprete esto como un rechazo C000 documentado; verifique los controles de discrepancia relacional 8 12 |
| Libro de Orthanc | Identificador de Orthanc igual, utilizando las cuatro entradas | El primer objeto se conserva de forma predeterminada; OverwriteInstances=true permite el reemplazo | Configuración instalada y respuesta real; esta página no proporciona una tabla universal de estados DIMSE 9 |
Fuente: Documentación de dcm4che Archive 5 etiquetada como 5.35 y Orthanc Book, revisados el 3 de noviembre de 2026. La configuración y las respuestas reales requieren verificación local.
¿El error describe Storage de imágenes o una operación DICOM diferente?
La operación del elemento de servicio de mensajes DICOM (DIMSE) debe acompañar a cualquier estado. Registre si la respuesta concierne a Storage C-STORE de imágenes, al paso de procedimiento realizado por la modalidad (MPPS) N-CREATE o a otro servicio, e identifique el objeto afectado. Una etiqueta de «fallido» a nivel de estudio puede combinar varias tareas; es evidencia insuficiente de qué imagen o informe falló.
PS3.7 C.5.8 define 0111H como Duplicate SOP Instance. La tabla B.2-1 de PS3.4 enumera por separado las respuestas de Storage C-STORE: éxito 0000H, advertencias que incluyen la coerción B000H y rangos de fallo tales como A7xx, A9xx y Cxxx. No enumera 0111H como un resultado estándar de C-STORE para duplicados. No convierta la definición genérica de estado en una regla universal de reenvío de imágenes. Si ese código aparece en un registro de Storage, consérvelo y consulte la documentación de implementación exacta del receptor. 5 6
Philips Lumify R5.0, documento HSDP-1299212, proporciona un ejemplo útil específico de ultrasonido. Su Tabla 18 enumera 0111H en las respuestas de MPPS N-CREATE. Dicha tabla no determina el resultado de un C-STORE de imagen. Un objeto MPPS y una instancia de imagen son registros diferentes. Utilice la guía relacionada para separar el estado del paso del procedimiento de la entrega de imágenes; verifique la entrega de imágenes de forma independiente en lugar de asumir el éxito o el fracaso a partir de MPPS. 10
Aplique la misma disciplina a nivel de objeto cuando un envío incluya tanto imágenes como un informe estructurado (SR). Identifique la SOP Class y la SOP Instance que fallan en lugar de asumir que cada objeto siguió la misma ruta. Este artículo no infiere la disponibilidad de mediciones discretas a partir de miniaturas de imágenes ni prescribe una clase de SR particular para todos los sistemas de ultrasonido.
¿Cómo se deben investigar los identificadores coincidentes con contenido diferente?
Una diferencia de contenido con una misma identidad es motivo para preservar la evidencia e investigar su origen. Primero determine qué difiere: la codificación del archivo, los metadatos de paciente/estudio, el contenido de píxeles, un recuento de fotogramas o los valores del informe. Registre qué comparación se realizó efectivamente. Una captura de pantalla puede revelar una diferencia de visualización; no puede determinar el contenido de cada instancia almacenada.
Una suma de comprobación del archivo completo puede identificar la igualdad de bytes en las copias comparadas, pero las sumas de comprobación desiguales no demuestran por sí solas un contenido clínico alterado. La información de metadatos del archivo, la codificación o los cambios de atributos documentados pueden diferir. Del mismo modo, los UID o las miniaturas coincidentes no demuestran equivalencia. Los propietarios calificados de los sistemas de la institución deben interpretar las diferencias de contenido mediante herramientas compatibles; esta guía no proporciona ningún umbral universal de aceptación de sumas de comprobación ni de diferencias de píxeles.
DICOM contempla explícitamente ciertos cambios en el lado del receptor. PS3.4 B.4.1.3 permite la coerción hacia el modelo de consulta del receptor, especifica una respuesta de advertencia (Warning) para dicha modificación y advierte sobre la integridad de las referencias. PS3.3 también describe registros opcionales de coerción, corrección o conversión. Por lo tanto, una transformación explicada y un cambio no explicado en el contenido de origen no deben clasificarse juntos. 1 7
- Compruebe el alcance exacto: La Tabla B.4-1 nombra Patient ID, Issuer of Patient ID, Other Patient IDs Sequence, Study Instance UID y Series Instance UID. La sección también aborda la conversión de secuencias de códigos y señala que otros atributos pueden corregirse. No constituye un permiso general para que los ingenieros de campo editen registros clínicos. 7
- Compare las advertencias con la configuración: el estándar exige un Warning para la coerción especificada. La documentación descriptiva de dcm4che señala que su retorno B000 está deshabilitado de forma predeterminada. Por lo tanto, la ausencia de esa advertencia no puede determinar que no haya ocurrido ningún cambio en un receptor desplegado. 6 7 8
- Solicite un registro de antes y después: Original Attributes Sequence e Instance Coercion DateTime pueden ser de ayuda donde contengan datos; no asuma que existen. Los cambios de estudio/serie pueden invalidar las referencias, por lo que debe consultar al propietario responsable del sistema cómo se conciliaron los objetos relacionados. 1 7
Si la exportación modificada implica compresión o derivación, utilice la guía independiente para rastrear el historial de compresión. Mantenga ese análisis diferenciado de una decisión sobre la política de reenvío. El hecho de que la sintaxis de transferencia negociada haya cambiado no determina, por sí solo, una nueva adquisición clínica ni un objeto dañado.
Los siguientes casos son resultados de comparación hipotéticos. Identifican la siguiente solicitud de evidencia y al responsable; no autorizan una fusión, una purga de cola, una reescritura de UID ni una transmisión repetida.
| Caso observado | Lo que respalda | Lo que permanece incierto | Siguiente responsable y evidencia |
|---|---|---|---|
| Misma identidad y mismo contenido inspeccionado | Compatible con una repetición en el alcance verificado | Objetos no inspeccionados y disposición real del receptor | Responsable del PACS: conciliar las listas de objetos esperados/retenidos e investigar la agrupación en el visor |
| Misma identidad SOP, diferencia de contenido no explicada | Una discrepancia que requiere preservación | Cambio de origen, transformación documentada o artefacto de comparación | Responsables del escáner/PACS: preservar las copias disponibles y rastrear la procedencia antes/después |
| Identidad diferente de estudio/serie/instancia | Los objetos se identifican de manera diferente | Exportación/corrección legítima frente a regeneración no intencionada | Proveedor del escáner: documentar el flujo de trabajo; responsable clínico/del PACS: evaluar los registros requeridos sin fusión forzada |
| Original o reintento real no disponible | Solo es posible una comparación parcial | Si se retuvo el primer contenido o el posterior | Responsables del PACS/escáner: buscar la evidencia restante de la transacción; dejar la etapa faltante sin resolver |
| El estado de duplicado corresponde a MPPS | La respuesta del objeto de procedimiento requiere su propia interpretación | Resultado de la entrega de imágenes | Responsable de integración: investigar MPPS; responsable del PACS: verificar los objetos de imagen por separado 10 |
Fuente: Ayuda editorial para la toma de decisiones fundamentada en las normas y los ejemplos de implementación citados; sin conjunto de datos clínicos ni estudio de validación.
¿Qué puede determinar una verificación de aceptación sintética autorizada?
Cuando un incidente no pueda resolverse a partir de los registros existentes, el proveedor del escáner y los responsables de la institución pueden acordar una prueba sin pacientes mediante su proceso de cambios aprobado. Utilice un entorno de prueba designado o un destino específicamente autorizado con una gestión controlada de registros de prueba. No interrumpa una red clínica ni inyecte objetos de prueba en registros de atención activos simplemente para reproducir un reenvío.
Acuerde la pregunta antes de realizar la prueba. Por ejemplo: ¿el reintento en cola documentado preserva las identidades de los objetos observados y qué retiene este receptor? Una nueva exportación después de una edición admitida es un caso de prueba independiente. La siguiente es una lista de verificación de planificación, no un procedimiento del fabricante ni una norma de aceptación clínica:
- Indique la configuración y los responsables. Registre el escáner/compilación, el receptor/versión, la ruta, la política de repetición vigente, el destino aprobado y quién controla los registros de prueba. Obtenga el procedimiento exacto de reenvío admitido.
- Defina el conjunto de objetos esperado. Utilice material sintético o de fantoma aprobado por la institución y adecuado para el sistema. Enumere las imágenes fijas, secuencias de cine y objetos de informe esperados cuando corresponda; esta guía no especifica ningún recuento arbitrario de fotogramas, ajuste de fantoma ni tolerancia de medición.
- Preserve la evidencia del primer envío. Capture el registro disponible de identidad/contenido saliente y los resultados de la operación antes de un reintento. Verifique por separado las copias de prueba retenidas por el receptor. Si no se puede acceder a la carga útil de origen por medios admitidos, documente esa limitación.
- Ejecute únicamente el caso de reintento acordado. Utilice el flujo de trabajo admitido bajo la supervisión de los responsables. La simulación de fallas requiere un método aprobado independiente; no desconecte un cable de red de producción ni modifique los controles de seguridad con base en este artículo.
- Complete el registro de tres etapas. Compare las identidades, el contenido dentro del alcance y la disposición real. Registre advertencias, fallas y evidencia no disponible. Si también se prueba la edición/reexportación admitida, consérvela como un evento independiente.
- Concluya con un resultado acotado. Indique lo que se demostró para esta versión, ruta, conjunto de objetos y configuración, lo que permanece sin probar y quién aprueba la siguiente acción. La institución conserva la autoridad sobre la disposición de los registros de prueba y el retorno al servicio clínico.
Una prueba exitosa demuestra únicamente la transacción probada. No puede reconstruir una carga útil clínica original perdida ni demostrar el comportamiento para cada flujo de trabajo del operador, SOP Class o versión futura. Vuelva a verificar después de actualizaciones del ecógrafo/archivo, migraciones o cambios de políticas. No se probó ningún ecógrafo, instalación de PACS ni corpus de imágenes de pacientes al preparar esta guía.
¿Qué evidencia corresponde al PACS y cuándo es relevante el servicio de hardware del ecógrafo?
El servicio de hardware se vuelve relevante cuando una investigación calificada proporciona evidencia independiente de fallas del lado del ecógrafo. La visualización de un estudio duplicado, un UID recién generado o un tiempo de espera agotado por sí solos no identifican una placa de E/S, unidad o placa base defectuosa. Mantenga los diagnósticos admitidos separados de la investigación del registro clínico y conserve los registros antes de cualquier recuperación autorizada de software o trabajo en las piezas.
Utilice la Tabla 4 para asignar la siguiente pregunta. Se trata de derivaciones propuestas, no de diagnósticos remotos ni de promesas sobre qué componente se puede reparar.
| Observación | Primer responsable | Evidencia que se debe solicitar | Implicación para el servicio de hardware |
|---|---|---|---|
| Dos entradas de estudio o mosaicos repetidos | Responsable del PACS/clínico | Identidades reales, inventario de objetos retenidos y agrupación del visor | Sin diagnóstico de componentes únicamente a partir de la visualización |
| Identidad modificada después de una exportación | Proveedor del ecógrafo y responsable de integración | Acción/compilación exacta y comportamiento documentado de generación o corrección | No infiera una memoria defectuosa ni una placa de procesador |
| Misma identidad con contenido modificado | Responsables del PACS/ecógrafo | Copias autorizadas, registros de transformación y método de comparación | Resuelva la procedencia antes de la recuperación o el reemplazo |
| Interrupción recurrente del transporte | TI e ingeniería clínica de la institución | Registros correlacionados de los extremos y diagnósticos admitidos de red/sistema | Puede justificar el servicio del ecógrafo si la evidencia independiente localiza una falla |
| Falla verificada del lado del ecógrafo | Proveedor calificado de servicio de ultrasonido | Modelo, software, resultados de diagnóstico y etiqueta accesible de la pieza | El diagnóstico de la placa/ensamblaje específico para el caso puede ser relevante 11 |
| Falta de evidencia original/de reintento | Responsables del PACS/ecógrafo | Registros restantes y descripción explícita de la etapa perdida | No sustituya la evidencia no disponible por una teoría de hardware |
Fuente: Ayuda editorial sobre responsabilidades; la capacidad de la empresa está delimitada por el alcance de servicio publicado de Rongtao.
Dónde encaja Rongtao — y dónde no
Rongtao Medical ofrece reparación de placas y ensamblajes de ultrasonido, servicio de sondas y diagnósticos a nivel de sistema. Una consulta de hardware es adecuada cuando el registro del incidente respalda el servicio del lado del ecógrafo en lugar de una visualización en el PACS que simplemente parece duplicada. Solicite una evaluación específica para cada caso; esta guía no establece compatibilidad de componentes, stock, reparabilidad, precio ni plazos de entrega garantizados. 11
Para esta investigación, la administración del archivo y la conciliación del registro clínico corresponden a la institución y a sus proveedores de sistemas. El servicio de reparación de Rongtao no constituye evidencia de que un archivo haya aceptado una instancia determinada o de que haya conservado el contenido correcto. Los nombres de los OEM identifican los equipos; no implican autorización ni respaldo por parte de dichos OEM.
Antes de realizar una consulta externa, prepare un resumen anonimizado de la observación y de los hallazgos de la institución. Conserve los objetos DICOM originales, los UID vinculados a pacientes, los números de acceso, las imágenes, las direcciones de red y los registros clínicos sin procesar dentro de los canales de soporte aprobados de la institución. Eliminar únicamente el nombre visible de un paciente no hace que una exportación sea apta para un formulario de cotización común.
Si los hallazgos respaldan el servicio de hardware, consulte los servicios de reparación de ultrasonido y envíe los detalles del equipo para la revisión de ingreso. Proporcione:
- OEM, modelo exacto del ecógrafo y versión del software host.
- Número de parte y revisión del fabricante, si ya se identificaron mediante un servicio autorizado; fotografías claras de la etiqueta y de ambos lados de la placa únicamente cuando el personal calificado pueda obtenerlas de forma segura.
- Síntoma depurado y texto exacto de error/estado, con la operación y la secuencia de eventos. Mantenga la información del paciente y los detalles de la red privada fuera de la cotización.
- Diagnósticos admitidos ya realizados y lo que determinaron los responsables de PACS/TI; identifique la evidencia faltante en lugar de suponer.
- Cantidad solicitada, país de destino y necesidades de plazos, para una cotización y condiciones de servicio específicas para el caso.
Preguntas frecuentes
¿Los números de estudio o recuentos de imágenes iguales demuestran un duplicado?
No. Una etiqueta de estudio o un recuento igual pueden ocultar conjuntos de objetos diferentes. Compare los identificadores y el contenido delimitado entre las etapas original, de reintento y retenida. Si solo se examinó una muestra, indique qué objetos se revisaron y cuáles permanecen sin verificar. La concordancia de pacientes, la identidad del objeto y la integridad clínica son conclusiones independientes.
¿Significa siempre 0111 que falló un reenvío de C-STORE?
No. Conserve la operación y el objeto afectado. La definición genérica de duplicado del estándar no establece un resultado universal de Storage, y la tabla de Lumify citada concierne a MPPS N-CREATE. El estado por sí solo no demuestra la entrega completa de imágenes ni una retención segura; solicite al responsable del archivo que verifique los objetos requeridos. 5 6 10
¿Puede un envío exitoso dejar el objeto anterior en su lugar?
Sí: el ejemplo NEVER de dcm4che devuelve explícitamente éxito mientras ignora la repetición. Solicite evidencia del contenido retenido y de la directiva aplicable. “Enviado con éxito” no es suficiente para determinar si una anotación posterior o una versión del informe reemplazó a una anterior. 8
¿Deberíamos generar nuevos UID para que el estudio sea aceptado?
No improvise nuevos UID para eludir el rechazo. DICOM advierte contra la derivación de nuevos identificadores mediante la adición de sufijos a los UID asignados en otro lugar. La corrección o derivación legítima corresponde a flujos de trabajo admitidos y controlados por los propietarios responsables del sistema, manteniendo la procedencia y las referencias. Esto es diferente de una solución provisional en campo que oculta la discrepancia original. 4
¿Qué sucede si el objeto saliente original ya no está disponible?
Marque esa etapa como no disponible. Busque los registros restantes del emisor y del receptor, pero verifique lo que realmente contienen: el alcance del registro, la retención y los identificadores varían. Un registro de transacciones puede ayudar a reconstruir la cronología y la disposición sin conservar la carga útil original. Si no permite determinar qué cambió, deje esa conclusión sin resolver en lugar de deducirla a partir de la captura de pantalla actual.
