Como puede inferirse de las necesidades antes planteadas, los sistemas PACS, utilizan varios componentes (hardware y software) con funciones específicas. Estos componentes son:

• Digitalizadores láser para placas de R-X.
• Digitalizadores de video.
• Estaciones de trabajo con diferentes características.
• Estaciones de consulta.
• Medios de almacenamiento óptico y magnético.
• Servicios de Impresión.
• Infraestructura para servicios de red.
• Servidores de Imágenes.
• Servidores de Bases de Datos.
• Dispositivos que generan imágenes médicas digitales.
• Servicios de comunicación a sistemas remotos externos.
• Otros...

Estos componentes se integran en un esquema Cliente/Servidor en una red, para ofrecer los diferentes servicios demandados por el área de radiología de un hospital y así cumplir con sus requerimientos.

Específicamente: 

• Promover la comunicación entre imágenes digitales independientemente del fabricante que las produjo.
• Ofrecer mayor flexibilidad a los sistemas de almacenamiento y comunicación de imágenes.
• Facilitar la creación y consulta a sistemas de diagnóstico por diferentes dispositivos y en diversos lugares locales o remotos.

Los primeros resultados en los trabajos de estandarización fueron publicados en 1985, ACR-NEMA Versión 1.0, teniendo como base, ideas obtenidas de formatos ya existentes. Por ejemplo, la definici>ón de elementos de datos de longitud variable identificados con etiquetas (formato de etiquetas), fue adoptada de un estándar para grabar imágenes en cinta magnética, desarrollado por la Asociación Americana de Físicos en Medicina (AAPM). Sin embargo, como todas las primeras versiones, se detectaron varios errores y el comité encargado(ACR/NEMA) autorizó a los grupos de trabajo involucrados, la realización de dos revisiones en Octubre de 1986 y en Enero de 1988, que produjeron una segunda versión, ACR-NEMA Versión 2.0, en 1988.

En esta nueva versión se conservaron prácticamente las mismas especificaciones de interfaz con hardware definidas en la versión 1.0, pero se agregaron nuevos elementos de datos y se corrigieron varios errores e inconsistencias. En esta versión se especificó la comunicación punto a punto entre dispositivos, un grupo de comandos por software y varios formatos de datos correspondientes a los nuevos elementos.

En el tiempo que se dio a conocer la segunda versión, surgió la demanda de interfaz entre dispositivos involucrados en la generación y manejo de imágenes y redes de ordenadores, sin embargo, el estándar no ofrecía ning&uacuete;n soporte de comunicación en red. La respuesta a estas demandas implicaba grandes cambios a lo ya establecido, considerando como restricción principal el mantener la compatibilidad con las versiones anteriores, lo cual fue un gran reto para los grupos de trabajo. De esta forma, a partir de 1988 se comenzó a trabajar en una tercera versión, en donde el proceso de diseño sufrió un cambio radical adoptando modelos para simular el mundo real, modelos de capas o pila para comunicación entre sistemas heterogéneos utilizando protocolos de comunicación en red y el modelo de cómputo Cliente/Servidor para establecer asociaciones entre dispositivos compatibles, a través del envío de mensajes.

Después de tres años de esfuerzo, se dio a conocer la versión ACR/NEMA DICOM (Digital Imaging and Communications in Medicine) llamada también DICOM 3.0, en la que participaron también varias instituciones de la comunidad internacional como JIRA (Japanese Industry Radiology Apparatus) y CEN (Comité Européen de Normalisation). Esta versión es considerada como un estándar completo, compatible con las versiones anteriores.

Las principales características de DICOM son:

• Intercambiabilidad de objetos en redes de comunicación y en medios de almacenamiento a través de protocolos y servicios, manteniendo sin embargo, independencia de la red y del almacenamiento físico. Todo esto a través de comandos definidos por una sintaxis y una semántica, a los que se les asocian datos. Las versiones anteriores sólo ofrecían comunicación punto a punto.
• Especificación de diferentes niveles de compatibilidad. Explícitamente se describe como definir un determinado nivel de compatibilidad, para escoger sólo opciones específicas de DICOM. En las versiones anteriores se especifica un nivel mínimo únicamente.
• Información explícita de Objetos a través de estructuras de datos, que facilitan su manipulación como entidades autocontenidas. Los Objetos no son únicamente imágenes digitales y gráficas, sino también estudios, reportes, etc.
• Identidad de objetos en forma única, como instancias con operaciones permitidas definidas a través de clases.
• Flexibilidad al definir nuevos servicios.
• Interoperabilidad entre servicios y aplicaciones a través de una configuración definida por el estándar, manteniendo una comunicación eficiente entre el usuario de servicios y el proveedor de los mismos.
• Representación de aspectos del mundo real, utilizando objetos compuestos que describen un contexto completo, y objetos normalizados como entidades del mundo real.
• Sigue las directivas de ISO en la estructura de su documentación multi-partes. De esta forma facilita su evolución, simplificando la adición de nuevas partes.

Los beneficios obtenidos de estos servicios son el poder crear una interface para los diferentes sistemas de información en un hospital, como los Sistemas PACS, Sistemas de información de radiología RIS (RIS: Radiology Information Systems) y sistemas de información administrativos HIS (HIS: Hospital Information Systems). En los sistemas PACS es donde su aplicación tiene mayor relevancia, dado que los servicios ofrecidos por DICOM pueden ser utilizados por los diferentes ambientes que generan y utilizan imágenes médicas de diagnóstico, manteniendo interoperabilidad entre ellos. Para cumplir eficientemente con los requerimientos operativos, cada uno de los componentes del sistema debe especificarse utilizando el estándar DICOM. Para DICOM cada componente de un sistema PACS, debe definir una o más entidades de aplicación (Aplication Entity: AE), que deben mantener cierto nivel de compatibilidad, de acuerdo a responsabilidades específicas. El objetivo es: evitar problemas de comunicación originados por errores de interpretación en la información.

Para la comunicación en ambiente de red, DICOM utiliza el modelo de capas para representar conexiones virtuales entre ambientes heterogéneos (diferentes plataformas de cómputo), utilizando protocolos de comunicación. Cada capa mantiene cierta responsabilidad en el manejo de la comunicación entre aplicaciones en la misma o en distintas máquinas. Para establecer una conexión virtual, los dispositivos que pretenden comunicarse deben utilizar los mismos protocolos en cada capa, para poder "hablar en el mismo idioma". En las versiones anteriores a DICOM, se hizo la especificación para comunicar dispositivos punto a punto. DICOM agrega la posibilidad de conexión en red utilizando como base los protocolos TCP/IP (Transmission Control Protocol/Internet Protocol) y los propuestos por ISO/OSI (International Standards Organization/Open Systems Interconnection). De esta forma se aprovechan los protocolos definidos en las capas inferiores tanto de TCP/IP como de ISO/OSI y define los protocolos necesarios en las capas superiores para soportar la comunicación entre aplicaciones en forma eficiente.

En el caso de ISO/OSI, aprovecha los servicios de las primeras 6 capas, además de los elementos de servicio OSI para la manipulación de asociaciones(ACSE).Para el caso de TCP/IP, especifica un protocolo de capa superior DUL(DUL: DICOM Upper Layer). Para ambos casos se definen un protocolo para aplicaciones DICOM, que permite la portabilidad entre ambos ambientes sin afectar las aplicaciones ya realizadas.

DICOM especifica la forma de comunicación, a través de asociaciones, estableciendo un ambiente cooperativo entre varias entidades en donde algunas juegan un papel de cliente, otras de servidor y otras de ambos, definiendo así un esquema Cliente/Servidor.

La forma de definir las reglas de cliente y servidor, es a través de la especificación de servicios específicos pertenecientes a entidades de aplicación que definen el nivel de compatibilidad deseado.