6 Descripción general del contenido del estándar DICOM

Estas partes de la Norma son documentos relacionados pero independientes. Se proporciona una breve
descripción de cada Parte en esta sección.

6.2 PS3.2: Conformidad

La PS3.2 del Estándar DICOM define los principios que las implementaciones que afirman conformidad
con el Estándar deben seguir:

• Requisitos de conformidad. PS3.2 especifica los requisitos generales que debe cumplir cualquier
implementación que alegue conformidad. Hace referencia a las secciones de conformidad de otras
partes de la Norma.
• Declaración de conformidad. PS3.2 define la estructura de una Declaración de conformidad. Especifica
la información que debe estar presente en una Declaración de conformidad. Hace referencia a las
secciones de la Declaración de conformidad de otras partes de la Norma.

PS3.2 no especifica un procedimiento de prueba / validación para evaluar la conformidad de una

implementación con el Estándar.

La Figura 6.2-1 y la Figura 6.2-2 representan el proceso de construcción de una Declaración de

conformidad tanto para la comunicación de red como para el intercambio de medios. Una declaración de
conformidad consta de las siguientes partes:

• Conjunto de objetos de información que esta implementación reconoce

• Conjunto de clases de servicio que admite esta implementación
• Conjunto de protocolos de comunicación o medios físicos que admite esta implementación
• Conjunto de medidas de seguridad que admite esta implementación.

Figura 6.2-1. Proceso de construcción para un reclamo de conformidad de red

Figura 6.2-2. Proceso de construcción para un reclamo de conformidad de medios

6.3 PS3.3: Definiciones de objetos de información

La PS3.3 del Estándar DICOM especifica una serie de Clases de Objetos de Información que
proporcionan una definición abstracta de entidades del mundo real aplicables a la comunicación de
imágenes médicas digitales e información relacionada (por ejemplo, formas de onda, informes
estructurados, dosis de radioterapia, etc.). Cada definición de clase de objeto de información consiste en
una descripción de su propósito y los atributos que lo definen. Una clase de objeto de información no
incluye los valores para los atributos que comprenden su definición.

Se definen dos tipos de clases de objetos de información: normalizados y compuestos.

Las clases de objetos de información normalizadas incluyen solo aquellos atributos inherentes a la
entidad del mundo real representada. Por ejemplo, la clase de objeto de información de estudio, que se
define como normalizada, contiene atributos de fecha y hora de estudio porque son inherentes a un
estudio real. Sin embargo, el nombre del paciente no es un atributo de la clase de objeto de información
del estudio porque es inherente al paciente en el que se realizó el estudio y no al estudio en sí.

Las Clases de Objetos de Información Compuesta pueden incluir adicionalmente Atributos que están
relacionados pero no son inherentes a la entidad del mundo real. Por ejemplo, la clase de objeto de
información de imagen de tomografía computarizada, que se define como compuesta, contiene atributos
que son inherentes a la imagen (por ejemplo, fecha de imagen) y atributos que están relacionados pero
no son inherentes a la imagen (por ejemplo, nombre del paciente) . Las Clases de Objetos de Información
Compuesta proporcionan un marco estructurado para expresar los requisitos de comunicación de las
imágenes donde los datos de imágenes y los datos relacionados deben estar estrechamente asociados.

Para simplificar las definiciones de la clase de objeto de información, los atributos de cada clase de objeto
de información se dividen con atributos similares que se agrupan. Estas agrupaciones de atributos se
especifican como módulos independientes y pueden ser reutilizadas por otras clases de objetos de
información compuesta.

PS3.3 define un modelo del mundo real junto con el modelo de información correspondiente que se
refleja en las definiciones de objetos de información. Las ediciones futuras de este estándar pueden
ampliar este conjunto de objetos de información para admitir nuevas funcionalidades.

Para representar una ocurrencia de una entidad del mundo real, se crea una instancia de objeto de
información, que incluye valores para los atributos de la clase de objeto de información. Los valores de
atributo de esta instancia de objeto de información pueden cambiar con el tiempo para reflejar con
precisión el estado cambiante de la entidad que representa. Esto se logra realizando diferentes
operaciones básicas en la instancia de objeto de información para representar un conjunto específico de
servicios definidos como una clase de servicio. Estas clases de servicio se definen en PS3.4 de la norma.

6.4 PS3.4: Especificaciones de clase de servicio

 PS3.4 del estándar DICOM define una serie de clases de servicio. Una clase de servicio asocia uno o
más objetos de información con uno o más comandos que se ejecutarán en estos objetos. Las
especificaciones de clase de servicio establecen los requisitos para los elementos de comando y cómo se
aplican los comandos resultantes a los objetos de información. Las especificaciones de clase de servicio
establecen los requisitos tanto para proveedores como para usuarios de servicios de comunicaciones.

La PS3.4 del estándar DICOM define las características compartidas por todas las clases de servicio y
cómo se estructura una declaración de conformidad con una clase de servicio individual. Contiene una
serie de anexos normativos que describen las clases de servicio individuales en detalle.

Ejemplos de clases de servicio incluyen lo siguiente:

• Clase de servicio de almacenamiento

• Consultar / Recuperar clase de servicio
• Clase de servicio de gestión de lista de trabajo básica
• Clase de servicio de gestión de impresión.

PS3.4 define las operaciones realizadas sobre los Objetos de información definidos
en PS3.3 . PS3.7 define los Comandos y protocolos para usar los Comandos para realizar las
operaciones y notificaciones descritas en PS3.4 .

6.5 PS3.5: Estructura de datos y semántica

PS3.5 del estándar DICOM especifica cómo las aplicaciones DICOM construyen y codifican la
información del conjunto de datos resultante del uso de los objetos de información y clases de servicios
definidos en PS3.3 y PS3.4 del estándar DICOM. Se especifica el soporte de varias técnicas de
compresión de imagen estándar (por ejemplo, JPEG sin pérdida y con pérdida).

PS3.5 aborda las reglas de codificación necesarias para construir un flujo de datos para ser transportado
en un mensaje como se especifica en PS3.7 del estándar DICOM. Este flujo de datos se produce a partir
de la colección de elementos de datos que componen el conjunto de datos.

PS3.5 también define la semántica de varias funciones genéricas que son comunes a muchos objetos de
información. PS3.5 define las reglas de codificación para los juegos de caracteres internacionales
utilizados en DICOM.

6.6 PS3.6: Diccionario de datos

PS3.6 del estándar DICOM es el registro centralizado que define la recopilación de todos los elementos
de datos DICOM disponibles para representar información, junto con los elementos utilizados para la
codificación de medios intercambiables y una lista de elementos identificados de forma única que son
asignados por DICOM.

Para cada elemento, PS3.6 especifica:

• su etiqueta única, que consiste en un grupo y un número de elemento,

• su nombre,
• su representación de valor (cadena de caracteres, entero, etc.),
• su multiplicidad de valores (cuántos valores por atributo),
• si está retirado

Para cada elemento identificado de forma exclusiva, PS3.6 especifica:

• su valor único, que es numérico con múltiples componentes separados por puntos decimales y
limitados a 64 caracteres,
• su nombre,
• su tipo, ya sea Clase de objeto de información, definición de codificación para transferencia de datos o
ciertas instancias de objeto de información bien conocidas,
• en qué parte del estándar DICOM se define.

6.7 PS3.7: Intercambio de mensajes

PS3.7 del estándar DICOM especifica tanto el servicio como el protocolo utilizado por una aplicación en
un entorno de imágenes médicas para intercambiar mensajes a través de los servicios de soporte de
 comunicaciones definidos en PS3.8 . Un mensaje se compone de una secuencia de comandos definida
en PS3.7 seguida de una secuencia de datos opcional como se define en PS3.5 .

PS3.7 especifica:

• las operaciones y notificaciones (servicios DIMSE) disponibles para las clases de servicio definidas
en PS3.4 ,
• reglas para establecer y terminar asociaciones proporcionadas por el soporte de comunicaciones
especificado en PS3.8 , y el impacto en las transacciones pendientes,
• reglas que rigen el intercambio de solicitudes y respuestas de comandos,
• reglas de codificación necesarias para construir secuencias de comandos y mensajes.

6.8 PS3.8: Soporte de comunicación de red para intercambio de mensajes

PS3.8 del estándar DICOM especifica los servicios de comunicación y los protocolos de capa superior
necesarios para admitir, en un entorno de red, la comunicación entre aplicaciones DICOM como se
especifica en PS3.3 , PS3.4 , PS3.5 , PS3.6 y PS3 .7 . Estos servicios y protocolos de comunicación
aseguran que la comunicación entre las aplicaciones DICOM se realice de manera eficiente y coordinada
en toda la red.

Los servicios de comunicación especificados en PS3.8 son un subconjunto adecuado de los servicios
ofrecidos por el Servicio de Presentación OSI (ISO 8822) y del Elemento del Servicio de Control de
Asociación OSI (ACSE) (ISO 8649). Se les conoce como el Servicio de capa superior, que permite a las
aplicaciones pares establecer asociaciones, transferir mensajes y terminar asociaciones.

Esta definición del servicio de capa superior especifica el uso del protocolo de capa superior DICOM junto
con los protocolos de transporte TCP / IP.

El protocolo de comunicación TCP / IP especificado por PS3.8 es un protocolo de comunicación de

propósito general no específico del Estándar DICOM. La Figura 5-1 muestra esta pila de protocolos.

6.9 PS3.9: Retirado (anteriormente Soporte de comunicación punto a punto para intercambio de
mensajes)

La PS3.9 del estándar DICOM especificó previamente los servicios y protocolos utilizados para las
comunicaciones punto a punto de manera compatible con ACR-NEMA 2.0. Ha sido retirado

6.10 PS3.10 Almacenamiento de medios y formato de archivo para intercambio de medios

La PS3.10 del Estándar DICOM especifica un modelo general para el almacenamiento de información de
imágenes médicas en medios extraíbles (ver Figura 6.10-1). El propósito de esta Parte es proporcionar
un marco que permita el intercambio de varios tipos de imágenes médicas e información relacionada en
una amplia gama de medios de almacenamiento físico.

Nota

Consulte la Figura 5-1 para comprender cómo se relaciona el modelo de intercambio de medios con el
modelo de red.

PS3.10 especifica:

• un modelo en capas para el almacenamiento de imágenes médicas e información relacionada en

medios de almacenamiento. Este modelo introduce el concepto de perfiles de aplicaciones de
almacenamiento de medios, que especifican subconjuntos específicos de la aplicación del Estándar
DICOM con los que una implementación de almacenamiento de medios puede reclamar
conformidad. Tal conformidad se aplica solo a la escritura, lectura y actualización del contenido de los
medios de almacenamiento.
• un formato de archivo DICOM que admite la encapsulación de cualquier objeto de información;
• un formato de archivo DICOM seguro que admite la encapsulación de un formato de archivo DICOM
en un sobre criptográfico;
• un servicio de archivos DICOM que proporciona independencia del formato de medios subyacente y
los medios físicos.

PS3.10 define varios conceptos de almacenamiento de medios:

 • el método para identificar un conjunto de archivos en un solo medio;
• El método para nombrar un archivo DICOM dentro de un sistema de archivos específico.

Figura 6.10-1. Modelo de comunicación DICOM para intercambio de medios

6.11 PS3.11: Perfiles de aplicaciones de almacenamiento de medios

La PS3.11 del Estándar DICOM especifica subconjuntos específicos de la aplicación del Estándar DICOM
con los que una implementación puede reclamar conformidad. Estos subconjuntos específicos de la
aplicación se denominarán Perfiles de aplicación en esta sección. Dicha declaración de conformidad se
aplica al intercambio interoperable de imágenes médicas e información relacionada en medios de
almacenamiento para usos clínicos específicos. Sigue el marco, definido en PS3.10 , para el intercambio
de varios tipos de información en medios de almacenamiento.

Un anexo del perfil de la aplicación está organizado en las siguientes partes principales:

• El nombre del perfil de la aplicación o la lista de perfiles de la aplicación agrupados en una clase
relacionada
• Una descripción del contexto clínico del perfil de la aplicación.
• La definición de la clase de servicio de almacenamiento de medios con los roles de dispositivo para el
perfil de aplicación y las opciones asociadas
• Sección informativa que describe los requisitos operativos del perfil de aplicación
• Especificación de las clases de objetos de información y objetos de información asociados admitidos y
la codificación que se utilizará para la transferencia de datos
• La selección de formatos de medios y medios físicos que se utilizarán.
• Otros parámetros que deben especificarse para garantizar el intercambio de medios interoperable
• Parámetros de seguridad que seleccionan las técnicas criptográficas que se utilizarán con el
almacenamiento seguro de medios Perfiles de aplicación

La estructura de DICOM y el diseño del mecanismo de Perfil de aplicación es tal que la extensión a
Clases de objetos de información adicionales y los nuevos medios de intercambio son sencillos.

Nota
 La Figura 6.11-1 muestra cómo los aspectos individuales de un perfil de Aplicación se asignan a las
diversas partes del Estándar DICOM.

Figura 6.11-1. Relación entre un perfil de aplicación y partes de DICOM

6.12 PS3.12: Funciones de almacenamiento y formatos de medios para el intercambio de datos

PS3.12 del estándar DICOM facilita el intercambio de información entre aplicaciones en entornos médicos
al especificar:

• Una estructura para describir la relación entre el modelo de almacenamiento de medios y un medio
físico específico y un formato de medios.
• Características específicas de los medios físicos y formatos de medios asociados.

6.13 PS3.13: Retirado (anteriormente Soporte de comunicación punto a punto de gestión de impresión)

PS3.13 especificó previamente los servicios y protocolos utilizados para la comunicación punto a punto
de los servicios de gestión de impresión. Ha sido retirado

6.14 PS3.14: Función de visualización estándar en escala de grises

PS3.14 especifica una función de visualización estandarizada para la visualización consistente de

imágenes en escala de grises. Esta función proporciona métodos para calibrar un sistema de
visualización particular con el fin de presentar imágenes consistentemente en diferentes medios de
visualización (por ejemplo, monitores e impresoras).

La función de visualización elegida se basa en la percepción visual humana. La sensibilidad al contraste

del ojo humano es claramente no lineal dentro del rango de luminancia de los dispositivos de
visualización. Este estándar utiliza el modelo de Barten del sistema visual humano.

6.15 PS3.15: Perfiles de seguridad y gestión del sistema

La PS3.15 del estándar DICOM especifica los perfiles de seguridad y gestión del sistema con los que las
implementaciones pueden reclamar conformidad. Los perfiles de seguridad y gestión del sistema se
 definen haciendo referencia a protocolos estándar desarrollados externamente, como DHCP, LDAP, TLS
e ISCL. Los protocolos de seguridad pueden usar técnicas de seguridad como claves públicas y "tarjetas
inteligentes". El cifrado de datos puede usar varios esquemas de cifrado de datos estandarizados.

Esta Parte no aborda problemas de políticas de seguridad. El estándar solo proporciona mecanismos que
pueden utilizarse para implementar políticas de seguridad con respecto al intercambio de objetos
DICOM. Es responsabilidad del administrador local establecer políticas de seguridad apropiadas.

6.16 PS3.16: Recurso de mapeo de contenido

PS3.16 del estándar DICOM especifica:

• plantillas para estructurar documentos como objetos de información DICOM

• conjuntos de términos codificados para usar en objetos de información
• un léxico de términos definidos y mantenidos por DICOM
• traducciones específicas de países de términos codificados

6.17 PS3.17: Información explicativa

PS3.17 del estándar DICOM especifica:

• anexos informativos y normativos que contienen información explicativa

6.18 PS3.18: Servicios web

PS3.18 del Estándar DICOM especifica los medios por los cuales los Servicios Web pueden usarse para
recuperar o almacenar un objeto DICOM.

Las solicitudes que recuperan datos especifican el tipo de medio (formato) del cuerpo de respuesta. Las
solicitudes que almacenan datos especifican el tipo de medio del cuerpo de la solicitud.

Las solicitudes HTTP tal como se definen en este Estándar son suficientes para que el servidor HTTP
actúe como una DICOM SCU (Usuario de clase de servicio) para recuperar o almacenar los objetos
solicitados de un DICOM SCP (Proveedor de clase de servicio) apropiado utilizando la funcionalidad
DICOM de línea de base como se define en PS3 .4 y PS3.7 , lo que quiere decir que el servidor HTTP
puede actuar como un proxy para el DICOM SCP.

6.19 PS3.19: Alojamiento de aplicaciones

PS3.19 del estándar DICOM especifica una interfaz de programación de aplicaciones (API) para un
sistema informático médico basado en DICOM en el que los programas escritos en esa interfaz
estandarizada pueden "conectarse" (ver Figura 6.19-1 ). Un implementador de sistema de alojamiento
solo necesita crear la API estandarizada una vez para admitir una amplia variedad de aplicaciones
alojadas adicionales.

Figura 6.19-1. Interfaz entre una aplicación alojada y un sistema de alojamiento

 En el modelo tradicional de "plug-in", el "plug-in" está dedicado a un sistema host particular (por ejemplo,
un programa de navegación web), y podría no ejecutarse en otros sistemas host (por ejemplo, otros
programas de navegación web). PS3.19 define una API que puede ser implementada por cualquier
sistema de alojamiento. Una aplicación hospedada "plug-in" escrita en la API podría ejecutarse en
cualquier entorno proporcionado por un sistema de alojamiento que implemente esa API (consulte
la Figura 6.19-2 ).

Figura 6.19-2. Ilustración de la independencia de la plataforma a través de la aplicación alojada

PS3.19 especifica las interacciones y las interfaces de programación de aplicaciones (API) entre los
sistemas de alojamiento y las aplicaciones alojadas . PS3.19también define los modelos de datos que
utiliza la API.

6.20 PS3.20: Informes de imágenes usando la arquitectura de documentos clínicos HL7

PS3.20 del estándar DICOM especifica plantillas para la codificación de informes de imágenes utilizando
el estándar HL7 Clinical Document Architecture Release 2 (CDA R2, o simplemente CDA). Dentro de este
alcance se encuentran los informes de procedimientos clínicos para especialidades que usan imágenes
para fines de detección, diagnóstico o terapéuticos.

PS3.20 constituye una guía de implementación para CDA y está armonizada con el enfoque de plantillas
estandarizadas para guías de implementación de CDA desarrolladas por HL7. También proporciona
nombres comerciales para elementos de datos que vinculan datos en la terminología del usuario, por
ejemplo, recopilados por una aplicación de creación de informes, a elementos codificados con CDA
específicos.

Como guía de implementación para informes de imágenes, se presta especial atención al uso y
referencia de los datos recopilados en los procedimientos de imágenes como evidencia explícita dentro
de los informes. Estos datos incluyen imágenes, formas de onda, mediciones, anotaciones y otros
resultados analíticos administrados como instancias DICOM SOP. Específicamente, esta Parte incluye
una especificación para la transformación en documentos CDA de instancias de informes estructurados
DICOM que representan informes de imágenes.

6.21 PS3.21: Transformaciones entre DICOM y otras representaciones

PS3.21 del estándar DICOM especifica las transformaciones entre DICOM y otras representaciones de la
misma información. Dentro de su alcance se encuentran las transformaciones hacia y desde el formato
de anotación y marcado de imágenes NCI.

7 Referencia al estándar DICOM

Según los procedimientos del Comité de Normas DICOM, la Norma está en constante revisión. Los
suplementos y las correcciones a la Norma se votan y aprueban varias veces al año. Cada cambio
cuando se aprueba como Texto Final entra en vigencia inmediatamente. A intervalos, todos los cambios
aprobados del Texto Final se consolidan en una edición publicada de la Norma, identificada por año de
 publicación, pero dicha publicación es solo una conveniencia para el usuario; el estándar se cambia
oficialmente cuando se aprueba cada cambio.

La conformidad con el Estándar DICOM es a través de Clases SOP especificadas utilizando mensajes
DIMSE (ver PS3.4 ), Servicios web (ver PS3.18 ), intercambio de medios (ver Anexo I "Clase de servicio
de almacenamiento de medios (Normativo)" en PS3.4 y PS3 .10 ), o la API de la aplicación alojada
(ver PS3.19 ). Se pueden hacer reclamos de conformidad adicionales a los Perfiles
(ver PS3.11 y PS3.15) Una vez que dicha unidad de conformidad se especifica en la Norma, todos los
cambios a la misma son compatibles con versiones anteriores y posteriores (excepto en casos
excepcionales en los que la especificación original no era interoperable o estaba en conflicto con otra
norma). Por lo tanto, los requisitos de conformidad y las declaraciones de conformidad se refieren al
nombre y / o identificador de la característica, y nunca se refieren a una edición de la Norma. En general,
la única referencia apropiada a una edición particular de la Norma es identificar una característica retirada
(consulte la Sección 1.4.2 Mantenimiento continuo ).

Se prefiere el siguiente formulario de citas para referencias generales a la Norma, sin especificar la fecha
de edición, cuando no se invocan requisitos de conformidad específicos:

NEMA PS3 / ISO 12052, Estándar de imágenes digitales y comunicaciones en medicina (DICOM),
Asociación Nacional de Fabricantes Eléctricos, Rosslyn, VA, EE. UU. (Disponible gratis
en http://www.dicomstandard.org/ )

Los requisitos de esta sección no anulan el requisito de proporcionar una Declaración de conformidad
DICOM como se describe en PS3.2 .

Se prefieren los siguientes formularios para referencias a unidades de conformidad con la Norma cuando
se realizan fuera del contexto de una Declaración de conformidad DICOM (por ejemplo, en los requisitos
del cliente):

• " ... conforme a la clase SOP DICOM <nombre> para el intercambio de red [como una clase de
servicio <usuario | Proveedor>], como se especifica en DICOM PS3.4 : Especificaciones de clase de
servicio. "
• " ... conforme a la clase SOP DICOM <nombre> para el intercambio de medios [como un conjunto de
archivos <Creador | Actualizador | Reader>], como se especifica en DICOM PS3.4 : Especificaciones
de clase de servicio. "
• " ... conforme al servicio web DICOM <nombre> [como <un servidor de origen | un User-agent>] [para
la <name> SOP Class], como se especifica en DICOM PS3.18 : Servicios web. "
• " ... conforme al alojamiento de aplicaciones DICOM [como un <sistema de alojamiento
| Aplicación alojada >] para la clase SOP <nombre>, como se especifica en DICOM PS3.19 :
Alojamiento de aplicaciones. "
• " ... conforme al perfil de aplicación DICOM <identificador> [como un conjunto de archivos <Creador
| Actualizador | Lector>] [para la <Nombre> Clase SOP], como se especifica en DICOM PS3.11 :
Perfiles de aplicaciones de almacenamiento de medios. "
• " ... conforme al perfil DICOM <nombre>, como se especifica en DICOM PS3.15 : Perfiles
de seguridad y administración del sistema. "

Nota

1. Algunos perfiles de aplicaciones y servicios web pueden especificar completamente los objetos
de información intercambiados, mientras que otros pueden requerir una especificación
explícita de las clases SOP en las referencias.
2. Ejemplos:
• “ La modalidad deberá cumplir con las Clases SOP de almacenamiento de imágenes
DICOM CT y de almacenamiento de imágenes MR para el intercambio de red como usuario
de clase de servicio, como se especifica en DICOM PS3.4 : especificaciones de clase de
servicio. "
• “ La estación de trabajo deberá cumplir con el perfil de aplicación DICOM STD-XA1K-DVD
como un lector de conjuntos de archivos, como se especifica en DICOM PS3.11 : Perfiles
de aplicaciones de almacenamiento de medios. "
• “ El PACS deberá cumplir con los servicios web DICOM WADO-RS y STOW-RS como
servidor de origen para las clases SOP enumeradas en la Tabla X, como se especifica en
DICOM PS3.18 : Servicios web. "
3. Dichas referencias no están permitidas en lugar de una Declaración de conformidad para un
producto. Por ejemplo, un producto que lee o crea medios de intercambio DICOM debe tener
una Declaración de conformidad (como se describe en PS3.2 ) que enumera los Perfiles de
aplicación de medios que implementa. Una declaración en algún otro formato, o un documento
 que describe que un producto admite la grabación de archivos de una Clase SOP particular
definida en PS3.4 , no es suficiente como alternativa a una Declaración de conformidad.

Se puede hacer referencia a otras características de la Norma, pero no deben interpretarse como
requisitos de conformidad DICOM (aunque pueden ser requisitos de conformidad para guías o
regulaciones de implementación que no sean DICOM). Los siguientes son algunos ejemplos:

• " ... Instancias SOP de acuerdo con la definición de objeto de información <nombre>, como se
especifica en DICOM PS3.3 : Definiciones de objetos de información. "
• " ... Instancias de SOP de informes estructurados utilizando la ID de plantilla DICOM <número y
nombre>, como se especifica en DICOM PS3.16 : Recurso de asignación de contenido. "
• “ … Instancias de CDA HL7 usando el ID de plantilla <identificador y nombre>, como se especifica en
DICOM PS3.20 : Informes de imágenes usando la arquitectura de documentos clínicos HL7. "
• " ... utilizando la sintaxis de transferencia <nombre>, como se especifica en DICOM PS3.5 : Estructura
de datos y semántica. "

Nota

Por ejemplo, los productos que producen o reciben documentos SR deben cumplir con una clase SOP,
como SR mejorada; dichos productos también pueden citar el uso del Informe de procedimiento de
ecocardiografía Template ID 5200, pero esa no es una afirmación formal de conformidad con DICOM. Sin
embargo, una guía de implementación que no sea DICOM, como el Perfil de flujo de trabajo de
ecocardiografía IHE, puede requerir el uso de esa Plantilla, y una implementación puede describir su uso
de Plantillas específicas en su Declaración de conformidad.

Dado que los cambios a la Norma no se citarán antes de la adopción como Texto Final, y dado que
después de la adopción son formalmente parte de la Norma, no debe haber citas de suplementos o
elementos de corrección con el fin de describir la conformidad. Se puede hacer referencia a dichos
documentos de cambio para describir el desarrollo histórico del Estándar DICOM.