IMPLEMENTACION DE PACS CON DISTRIBUCION WEB

Presentado a:
ING. ALEJANDRO RODRIGUEZ

Presentado por:
ANGELICA FRANCO
CAMILO LOZADA
CAMILA OLIVEROS

EQUIPOS DE IMAGENOLOGIA
FACULTAD DE INGENIERIA BIOMEDICA
UNIVERSIDAD MANUELA BELTRAN
BOGOTA
OCT-2010
 INTRODUCCION

Con la llegada de la era de los equipos de imagenología digitales al diagnóstico médico se

empezó a implementar en los centros hospitalarios la forma de compartir y administrar las
imágenes obtenidas con estos dispositivos. Esto permite de muchas formas disminuir
costos en las instituciones de salud y contribuir en la disminución de la producción de
residuos hospitalarios y similares. El inconveniente generado ante este nuevo reto es el
costo asociado a la implementación de un sistema de gestión de imágenes médicas debido
no solo a las diferentes marcas de equipos biomédicos existentes en el centro médico y la
diferencia de formatos de imagen existentes sino también a la seguridad y privacidad que
se debe garantizar a esta información.
El objetivo de este proyecto es diseñar e implementar un sistema de gestión de imágenes
médicas para las modalidades de MRI, CT y PET, que utilice herramientas gratuitas y que
cuente con distribución web dentro del centro hospitalario, además de capacidad de
almacenamiento por cinco años y la seguridad reglamentada para este tipo de datos.
 MANEJO DE LOS DATOS DEL PACIENTE

HL7 es un estándar para la interoperabilidad de sistemas informáticos en salud que inició

en 1987 y ahora está en 30 países [2].

La última versión de HL7 es la V3 que consiste en:

 HL7 V3 está basada y expresada en el estándar XML y sus derivados.

 Para entender, diseñar mensajes y/o desarrollar una interface HL7 V3 requerirá
conocimientos intermedios a avanzados de:
 XML: los mensajes se expresan como documentos XML.
 Schemas XML: la especificación de la estructura de los mensajes se realiza a través
de un Esquema XML.
  XSL: a través de este estándar se puede transformar un documento o mensaje en
un documento HTML
 X-PATH: a través de este estándar no basado en xml se puede ‘interrogar’ a un
documento XML como si fuera un árbol de directorio.
 XSLT: permite modifica la estructura de un documento XML transformandolo en
un nuevo documento XML con otra estructura.
 DOM/SAX o algún otro medio de procesamiento de XML.

Versiones:

 CDA (CLINICAL DOCUMENT ARCHITECTURE): Es una especificación para

intercambio de documentos utilizando XML, el modelo de información de HL7
(RIM), la metodología de HL7 V3 y vocabularios controlados o locales (SNOMED,
ICD, LOINC, etc.). Define el marcado de documentos para especificar la semántica y
la estructura.
 CCOW: Framework para compartir aplicaciones y permitir un login único.
 Arden Sintax: Es una Sintaxis If/then para compartir reglas de conocimiento clínico
[3].

Además de estas herramientas en internet se encuentran algunas ya desarrolladas como

google health que permite a los pacientes ingresar los datos de su historia clínica, para
luego compartirlos con quienes el usuario autorice (médicos e instituciones médicas). De
esta manera, la historia clínica personal es accesible desde cualquier parte del mundo con
acceso a internet. El sistema permite la carga de diagnósticos, medicaciones,
almacenamiento de resultados de estudios de laboratorio e inmunizaciones. Otro
software análogo es KEYOSE que para la gestión del historial medico asigna un numero de
identificación único para la consulta y modificación de la misma.
 PROTOCOLO DE GESTION DE IMÁGENES
DICOM

IMAGENES
BIOMEDICAS

ESTRUCTURAL FUNCIONAL

Ultras
onidos
MRS

fMRI
MRI
Microscopio MSI
CT por RX ESI
Imágenes
Electr Ópticas
ónico Confo Médicas
RX cal CT por
emisión

CR
DSA MEG
MKG
RX Convensional
Mamografía PET
SPECT

Grafico 1: Clasificación de imágenes médicas [1]

El protocolo Dicom nació con el fin de promover la comunicación entre imágenes médicas
sin necesidad de que estas hayan sido creadas a partir de equipos del mismo fabricante y
poder administrarlas por medio de redes tanto dentro como fuera de la institución de
salud.
Dicom permite dentro de sus funciones distribuir la información desde y hacia los
diferentes departamentos del centro hospitalario, almacenamiento de las imágenes y los
datos básicos del paciente al que pertenecen, impresión, visualización de imágenes desde
cualquier otro dispositivo, observar cuantos estudios se han realizado a los pacientes,
observar imágenes en simultanea con otros departamentos del centro hospitalario,
garantizar el mismo formato de la imagen, contar con listas de trabajo del equipo, e
incluso gestionar datos también.
En Dicom se habla de procesos distribuidos que son actividades en las que se comparte
información. En estos casos un proceso depende del otro y de esta forma se define el
cliente y el servidor; esto es, el cliente para funcionar utiliza la operatividad del otro, el
servidor por el contrario es el que se encarga de administrar la información existente. Para
que esta relación se lleve a cabo normalmente es necesario definir los parámetros bajo los
cuales se establece la relación y estar de acuerdo en la información que intercambian.
En este protocolo existen distintos tipos de objetos (datos de información) entre los que
se encuentran pacientes, imágenes, reportes, etc., y para su almacenamiento se
encuentran clasificados de acuerdo a la estructura de datos que representan, por ejemplo
todos los nombres son de tipo PN (Person Name), todas las fechas de tipo DA (Date), entre
otros [4].
La idea de utilizar este protocolo en el proyecto se basa principalmente en que se
encuentra estandarizado y actualmente muchos equipos de reconocidas marcas generan
sus imágenes con este formato, además porque es actualizado constantemente y permite
la distribución de información por diversos medios, entre ellos por medio de un servidor
web.

ESTRUCUTRA DE DATOS EN EL ESTANDAR DICOM

Un archivo (objeto) Dicom consiste en un alista de datos (atributos) que contienen

imágenes relacionadas con información. Entre estos datos esta el paciente que tiene datos
como nombre, sexo, fecha de nacimiento; el medio y procesamiento de la imagen que
tiene datos como parámetros del equipo con el que se tomo el examen y calibraciones; e
información como tal de la imagen como por ejemplo la resolución.

INTERCAMBIO DE MEDIOS DE COMUNICACIÓN [1]

Además de la comunicación de imágenes medicas sobre la red, el intercambio de medios

de comunicación se ha hecho hueco en DICOM que fue integrado en el estándar en 1996.
Los campos de aplicación son por ejemplo el almacenaje de películas de angiografías en la
cardiología o el almacenaje de imágenes de ultrasonido. Para asegurarse de que los
medios de comunicación de almacenaje DICOM son realmente intercambiables, el
estándar define los llamados “perfiles de aplicación” que define:

 que modalidades de imágenes pueden estar presentes en el medio

 que formatos de codificación y compresión pueden ser usados
 que medio de almacenaje es usado

Cada medio DICOM contiene un llamado “DICOM directorio” además de los archivos de
imagen. Este directorio contiene la información más importante (el nombre paciente, la
modalidad, identificadores únicos, etc.) para todas las imágenes en el medio. Esto permite
hojear o buscar rápidamente a través de todas las imágenes del medio sin tener que leer
el archivo imagen completo.

DECLARACION DE CONFORMIDAD

DICOM requiere que una “Declaración de Conformidad” (Conformance Statement) sea

escrita para cada dispositivo o aplicación desarrollada con DICOM. El formato y el
contenido de esta declaración son definidos en el estándar. Esto explica que servicios
DICOM y opciones son soportados, que extensiones y particularidades han sido puestas en
práctica por el vendedor, y como el dispositivo se comunica con otros sistemas DICOM. En
la teoría, comparando dos declaraciones de conformidad permite determinar si dos
dispositivos DICOM son capaces de comunicarse el uno con otro. En la práctica, sin
embargo, las declaraciones de conformidad son solo comprensibles para expertos y son
con frecuencia inadecuados. DICOM ha llegado a ser un indispensable componente para la
integración de sistemas de imágenes digitales en medicina. DICOM ofrece soluciones para
una multitud de comunicaciones relacionadas con las aplicaciones. La palabra “DICOM”
por si misma no garantiza una integración “de enchufar y listo” de todos los sistemas de
información de un hospital. Esto requiere una combinación cuidadosa de todas las
soluciones parciales ofrecidas por DICOM.

CLASES Y SERVICIOS SOPORTADOS POR DICOM [1]

DICOM tiene definidas un número de Clases de Servicio. Pueden ser agrupadas en un gran
número de categorías. Esta lista de Clases de Servicio crecerá tal como nuevas
operatividades sean estandarizadas en el estándar DICOM.

Image Storage Service Classes

Esta primera categoría contiene las Clases de Servicio negociadas con los datos de imagen.
Los datos de imagen son siempre encapsulados en un IOD compuesto y utilizando los
servicios compuestos. Las Clases de Servicio de este grupo son:

 Storage Service Class

Que consiste en Clases SOP para cada modalidad de tipo de imagen: Computed
Radiography (CR), Computed Tomography (CT), Magnetic Resonance (MR), etc. Esta
Clase de Servicio especifica el intercambio de los datos a través de la red. No especifica
que se tiene que hacerse con la imagen, ni que tiene que ser gestionada por otras
Clases de Servicio.

 Query/Retrieve Service Class.

Incluye las clases SOP FIND, MOVE y GET para un número de modelos de peticiones. La
FIND puede ser utilizada para solicitar una colección de imágenes. La MOVE y GET
pueden ser usadas para iniciar la transferencia. La actual transferencia se realiza
utilizando la Storage Service Class.

 Study Contents Notification

Es utilizada para notificar una administración fácil de una imagen sobre las imágenes
creadas durante un estudio y podrían ser utilizadas para iniciar la transferencia de los
datos de imagen o para chequear si todas las imágenes han sido completamente
transferidas.

Management Service Classes

La administración orientada a las Clases de Servicio se realiza utilizando una mezcla de

IODs normalizados con Servicios normalizados y una Clase de Servicio Query que maneja
información en sentido opuesto. Esta segunda categoría consiste en:
  Detached Patient Management
Maneja la información solicitada por la agenda de visitas para una o más modalidades.
La información demográfica del paciente y los estudios de información son enviados
desde los sistemas administrativos (RIS) hasta la modalidad.

 Detached Study Management

Recibe información de las series de imágenes creadas de las modalidades y manda
todos los datos adquiridos a un completo estudio de imágenes interdependientes y
todos los otros tipos de información.

 Detached Result Management

Es utilizada para estar al tanto de los informes e impresiones del estudio.

 Basic Worklist Management

Es la única Service Class no normalizada. Complementa a la Detached Patient, Study y
Result Management Service Class con una fácil petición, para ser utilizada para
obtener información sobre una única lista de entidades de información. Esto permite
una forma más flexible de adquirir información comparada con las otras Clases de
Servicio.

 Print Management
Se utiliza para administrar el proceso de formateo e impresión de una colección de
imágenes en una cinta.

Media Storage Service Class

En Media Storage Services class son definidos un set de servicios que permiten el
intercambio de datos usando Media Storage. Media es usado por dos razones:

1. Las imágenes son almacenadas en Media para el intercambio entre dos procesos sin la
especificación sobre el tratamiento, solamente la transferencia de la información.
2. Las imágenes son almacenadas para mostrarlas como Sesiones de Película. El proceso
de recepción debe manejar la información de la Gestión de la Impresión en Media, y
mantener sobre ésta la información del estado del progreso del trabajo de impresión.

PROPUESTA DE DISEÑO

Se propone diseñar un PACS con protocolo DICOM con distribución web dentro del
hospital que soporte las siguientes modalidades de imágenes diagnosticas:

 Resonancia magnética (MRI).

  Tomografía (CT).
 Tomografía por emisión de positrones (PET).

El sistema además de las características anteriormente mencionadas debe almacenar las

imágenes por 5 años.

IMPLEMENTACION

Nos proponemos implementar dcm4che que es una colección de aplicaciones y utilidades

“open source” que explicaremos a continuación [5].

DCM4CHE

Los componentes de dcm4che trabajan juntos de manera tal que proveen una referencia
para la implementación de muchos perfiles de integración IHE. Dcm4che es un sistema
multiplataforma. Esta desarrollado en java, solo se utilizo C/C++ para las librerías de
compresión (los codecs gratuitos de sun para el manejo avanzado de imágenes en java), y
distribuido como un grupo de componentes integrados JEE (java Enterprise edition) en un
servidor de aplicaciones.

dcm4chee utiliza una base de datos para almacenar la información de las cabeceras
DICOM, información de índices para localizar objetos en el sistema de archivos, y otros
datos clínicos pertinentes del sistema. Seis diferentes bases de datos son compatibles para
la implementación con el sistema:

 PostgreSQL
 MySQL
 Oracle
 SQL Server
 DB2
 Firebird
 HSQL

Cualquier visualizador de imágenes médicas que sea capaz de comunicarse por medio de DICOM
puede ser fácilmente integrado con dcm4che como se muestra en (A) de la imagen a continuación.
Esta forma de comunicación se dará por medio de DICOM query (C-FIND), y DICOM retrieve (C-
MOVE) para localizar y recuperar las imágenes en el equipo local. Ya las imágenes se podrán ver,
manipular, y potencialmente re-almacenar (por medio de DICOM C-STORE) de nuevo en el mismo
archivo si se han modificado.
Adicionalmente a la integración DICOM estándar, dcm4che tiene una aplicación web, como se
muestra en (B). dcm4che utiliza HTTP para realizar la comunicación entre el archivo y un
navegador estándar. Dcm4che utiliza el estándar WADO para visualizar las imágenes en el
navegador por lo tanto solo se podrá visualizar una imagen a la vez, debido a esto es necesario
implementar una herramientas java que se active con el navegador y que nos permitan trabajar de
manera técnica con las imágenes para que así el diagnostico se realice y se almacene dentro del
mismo servidor web.
Esquema general del sistema dcm4che implementado.
Dcm4che contiene servicios e interfaces de DICOM y HL7 que son necesarios para proveer
almacenaje, recuperación y flujo de datos.

Servicio Descripción
Interface web para Dcm4che contiene una interface de usuario robusta para
usuario administradores que corre enteramente en un navegador de
web.
DICOM Storage Dcm4che tiene la capacidad de almacenar cualquier tipo de
objeto DICOM como archivos del sistema, comprimido si es
necesario.
DICOM Q/R Busca los objetos DICOM y los despliega.
WADO (web access to Acceso web al contenido web.
DICOM objects) y RID
(retrieve information
for display)
Otros servicios DICOM MPPS, GPWL, MWL, Storage Committment, Instance
Availability Notification, Study Content Notification, Output
Content to CD Media, Hanging Protocols, y mas.
Servidor HL7 Un servidor HL7 que actúa sobre mensajes de tipo ADT, ORM y
ORU.

INTERFACE WEB DEL USUARIO

La interface del usuario consiste en muchas páginas web dinámicas, se denomina

dcm4chee-web y contiene las siguientes funciones:

 Administración del contenido almacenado.

 Trash.
 AE Management.
 Offline Storage.
 Worklist Console.
 MPPS Console.
 User Administration.
 Audit Record Repository.
 SERVICIOS DICOM

DICOM Security Service

Toma la información del usuario que accede al sistema y responde con el perfil adecuado
para el usuario.

DICOM Server

Envía las solicitudes entrantes de servicio a servicios DICOM registrados.

General purpose worklist feed service (GPWL Feed)

Lo usa la interfaz web para añadir entradas a la lista de propósitos generales (GPWL)
General purpose worklist SCP

General purpose worklist SCU

Hanging protocol SCP

Instance Availability Notification SCU

Se utiliza para notificar acerca de las instancias DICOM disponibles.

Media Creation Management SCU

Define cuando y como se crean los medios.

Modality Performed Procedure Step Emulator

Emula los mensajes MPPS de los objetos recibidos de las modalidades que no soportan
MPPS, que son procesados por el procedimiento de las modalidades denominado STEP
SCP de la misma manera que los procesan las modalidades que si soportan MPPS.
Modality Performed Procedure Step SCU

Se usa para reenviar los mensajes MPPS recibidos por el MPPS SCP.

Modality Worklist Replication Service

Provee la capacidad de replicar un MWL SCP con la modalidad worklist de dcm4che. Se

pueden usar plataformas XSL para cambiar solicitudes C-FIND de MWL a MWL SCPs.
Modality Worklist SCP

Las entradas worklist son creadas, actualizadas y borradas por medio del servicio ORM
cuando se reciben las ordenes HL7 (ORM^001). Su estado inicial puede cambiar a ARRIVED
por medio del servicio ADT activado por el mensaje HL7 (ADT^A10). Mas adelante su
estado cambiara a STARTED, COMPLETED o DISCONTINUED cuando se reciban los
mensajes DICOM MPPS provenientes de la modalidad PPS SCP.

 Query Modality Worklist

Modality Worklist SCU

Utilizada por la consola de la modalidad worklist de la herramienta de administración del

archivo web del servicio storage SCP para consultar la configuración de la modalidad
worklist SCP para el procedimiento a seguir.
Move SCU Service

Para procesar ordenes de mover. Invoca las solicitudes DICOM de recuperación,

usualmente desde el archivo propio Q/R SCP de DICOM. Estas mismas funciones de mover
y reenviar están disponibles en las herramientas de administración web.

Private Study Management SCP

Private Study Management SCU

Es usado para reenviar mensajes recibidos por el PSM SCP.

Query Retrieve SCP

DICOM Storage SCP

Proporciona un servicio de almacenamiento DICOM para recibir los objetos DICOM desde
aplicaciones remotas de DICOM.

Storage Commit Service

Define si se encuentra en el rol de proveedor o cliente del servicio de almacenamiento.

Teaching File and Clinical Trial Export Manager
 HL7

HL7 Send Service

Emite mensajes a los receptores de HL7. Puede ser configurado para reenviar los mensajes
recibidos por el servidor de HL7 a otros sistemas. También es utilizado por el Servicio de
Información XDS-I para consultar el administrador de referencia cruzada de pacientes para
averiguar la identificación de un paciente en diferentes dominios.

HL7 Server

Despacho de entrada de mensajes HL7 de servicios HL7 registrados. Cuando lo configure,

seleccione el puerto TCP de escucha, el protocolo de seguridad para la comunicación, los
tiempos de espera, y el número máximo de remitentes HL7.
ADT Service

Recibe y procesa los mensajes ADT entrantes, con base en los mensajes que se aceptan tal
como se define en los atributos. Si un registro de pacientes no existe en la base de datos
del paciente en el mensaje ADT de entrada, se crea uno. Tenga en cuenta que los
controles ADT^A10 de los mensajes no afectan a la historia clínica del paciente, sino que si
existen elementos pendientes de listas de trabajo para este paciente gestionados por el
archivo, estos cambian el estado de la lista de trabajo del elemento que llega.

ORM Service

Crea, actualiza o borra entradas de la lista de trabajo proporcionadas por la Modalidad

worklist SCP de acuerdo a los mensajes ORM^O01 recibidos. En general, este servicio se
utiliza si la RIS conectada no puede proporcionar la modalidad worklist.
Procedimiento programado

Procedimiento actualizado

Esquema
ORU Service

Convierte ORU^R01 en informes estructurados, por lo que un visualizador puede usar el

sistema de PACS para acceder al informe.

MDM Service

Convierte mensajes MDM^T02/T10 a codificación Base 64 en formato PDF de acuerdo a la

tarjeta 7 IHE de transacción: Presentación encapsulada de informes, documentos
encapsulados PDF en DICOM, para que puedan ser recuperados por el RID DICOM IHE.

MPPS to ORM Service

Convertidor de MPPS DICOM a ORM HL7. Convierte el procedimiento realizado por la

modalidad DICOM MPPS SCP a un mensaje ORM de HL7 enviado a cualquier receptor HL7.
Este servicio puede ser usado con sistemas RIS que no pueden manejar mensajes MPPS.
PIX Query Service

Se usa para buscar la identificación de un paciente en diferentes dominios consultando la

base de datos de pacientes relacionados con IDs de otros pacientes o enviando un
mensaje QBP^Q23 v2.5 al identificador de referencia cruzada y evaluando el mensaje HL7
v2.5 RSP^K23 recibido.

Prefetch Service

Pre-busca estudios que no se encuentran ya disponibles desde un archivo externo o

adjunto a un almacenamiento cercano para una orden de mensaje (ORM^O01) del
paciente.
Study Permission Service

Concede o revoca los permisos de acceso a los estudios a roles particulares de los
mensajes HL7 recibidos, mensajes MPPS N-CREATE, series almacenadas o por interaccion
directa con el usuario.

WADO (web access to DICOM objects) y RID (retrieve information for display)

RID Service

Recupera información para el servicio de visualización. Provee una fuente de información

RID con soporte para ECG.
Esta fuente de información se basa en archivos DICOM y por lo tanto solo permite acceso
a documentos DICOM (reportes estructurados, formas de onda (RID-ECG) y encapsulados
PDF). Los objetos DICOM enumerados pueden ser consultados por medio de peticiones de
recuperación de información RID y son representados (en cache) como documentos PDF
para peticiones de recuperación de documentos RID.
WADO Service

Proporciona un servidor Web habilitado para DICOM que permite el acceso Web para
objetos persistentes DICOM. Esta aplicación utiliza el soporte de consultas relacionales.
Por tanto, los parámetros de petición studyUID y seriesUID pueden estar vacíos. (No está
permitido omitir estos parámetros debido a especificaciones WADO). Redirigir: Si este
servicio WADO controla una solicitud para un objeto que es recuperable externo, se
iniciara una redireccion del lado del cliente o el servidor.
 HSM (ALMACENAMIENTO)

File Copy Service

Servicio de copia de archives

Synchronize File Status Service

Comprueba el servicio de archivos de estado.

TAR Retriever Service

Servicio de e] cuperación TAR.

XDS
(REPOSITORIO DE DOCUMENTOS-FUENTE DE IMAGENES DE DOCUMENTOS)

Key Object Generation Service

Servicio para la generación de objetos clave.

XDS-I Information Source Service

Se usa para compartir imágenes de documentos dentro de la institución.

XDS Repository Service

Sirve para compartir las reposiciones de los objetos dentro de la institución.

XDS Store2Dcm Service

Provee el servicio para almacenar documentos XDS como objetos DICOM encapsulados en
archivos DICOM.

SERVIDORES

Para instalar todo (base de datos y dcm4chee) en una máquina, es bueno tener una gran
cantidad de memoria y potencia de procesamiento para satisfacer las necesidades del
sistema. Volumen, tipo de imágenes, el número de usuarios simultáneos (DICOM, HL7, y
humanos), y los requisitos de rendimiento. En general es una buena idea ejecutar la base
de datos y el sistema dcm4chee en máquinas separadas en un entorno de producción.
Habrá sobrecarga de la red entre los dos servidores, pero el beneficio está en la
dedicación de la memoria adecuada, los procesadores y de almacenamiento para cada
aplicación (dcm4chee y base de datos).

El servidor debe cumplir con estos requisitos minimos:

 Soportar navegadores web conectados a través de internet.

 Interpretar consultas requeridas desde el navegador web en HTLM o java y los
convierte en archivos estándar DICOM y HL7.
 Soporta Q/R de DICOM (service object pair) para consultar y recuperar
imágenes/datos y los convierte en HTLM.
Arquitectura básica de un servidor web que permite a los navegadores realizar Q/R para
imágenes y datos. El interprete DICOM/HTTP es clave [6].

Sesión típica de Q/R del servidor [6].

La tecnología mas adecuada para los servidores implementados en PACS son los Ethernet
gigabit por lo tanto el servidor a implementar es:
GIGA-INTERNATIONAL SERVER 6-CORE

Procesador Intel core i7 (6x 3,20GHz)

RAM 24GB
Disco duro 80GB SSD, 2000 GB HDD
Puertos Ilimitados
Ancho de banda 100Mbits/s
Sistema operativo Linux y windows (2003/2008)
Upstream 2x10 Gbits/s fibra óptica

Características de las imagenes médicas

 Tomografía computarizada: Imagen Digital, matriz: 512 x 512 x 2 bytes.

imagenes/estudio: 40, Imagen reconstruida a partir de multiples proyecciones de
un haz de rayos X.
 Resonancia magnética: Imagen Digital, matriz: 256x 256 x 2 bytes,
imágenes/estudio: 100, campos magneticos miden la densidad espacial de los
protones de hidrogeno.
Teniendo en cuenta que una resonancia magnética tarda en promedio 30 min y esperando
que el equipo trabaje 16 horas diarias entonces, se harán unos 32 examenes diarios lo que
se traduciría en en 800 Mb de almacenamiento diario, es decir 4 Gb semanales, 16 Gb
mensuales, 192 Gb al año y 960 Gb en los 5 años que son el límite de almacenamiento.
En el caso de la tomografía computarizada, el tamaño de la imagen es de
aproximadamente 32 MB y con un tiempo de 20 minutos se hacen aproximadamente 48
examenes diarios lo que significa 1,5 Gb de memoria al dia, 7.6 Gb semanales, 30,7 Gb
mensuales, 368,6 Gb al año y 1.8 Tb como límite de almacenamiento a los 5 años.
Para el PET el tiempo de duración de la prueba se estima en 60 minutos, por lo que solo se
realizarían 16 exámenes diarios por lo que se necesitan 800 Mb de almacenamiento diario
y 960 Gb en 5 años.

Dado que el sistema que se desea implementar con estas tres modalidades, se requiere un
sistema de almacenamiento de por lo menos 4 Tb para poder dar soporte de 5 años. Para
suplir esta necesidad de capacidad de almacenamiento se planea utilizar el sistema
ProStor Systems que es un desarrollador de sistemas de almacenamiento de discos
removibles en las empresas, para el soporte y conservación de datos, suministrando los
beneficios del almacenamiento en línea con la economía del almacenamiento fuera de
línea. ProStor InfiniVault virtualiza el disco removible con el disco en red para disminuir los
costos de retención de datos y el consumo de energía. Además, es capaz de administrar
más de mil millones de estudios en formato DICOM. Cada cartucho de disco removible de
500 GB. El costo de este sistema por los 5 años se calcula en $89,995.

ESTACIONES DE DIAGNOSTICO

Las estaciones de diagnostico son diferentes a los visualizadores web, las primeras
requieren monitores de características especiales que nos permiten visualizar mayor
numero de cortes en un solo pantallazo y en los visualizadores web solo veremos un solo
corte en la pantalla y la calidad de la imagen no es del todo confiable por la distribución de
grises, por lo tanto aparte de los computadores normales que se utilizaran como
visualizadores web se implementara una estación de diagnostico para cada modalidad, la
estación de diagnostico es la siguiente:

DOME 3MP
Mini torre Dell con procesador de 3GHz
4GB de memoria RAM
Monitor administrativo LCD de 19’’
HD de 250GB
Dos bahías para tarjetas de video PCI
 FORMATO DE REQUERIMIENTOS PARA IMPLEMENTACION DE PACS CON SERVIDOR WEB

INFORMACION DE LA INSTITUCION

Nombre de la institución:

Nivel de la institución:

Ciudad:

INFORMACION TECNICA

Se tiene servidor web dentro de la

institución:

Que especificaciones técnicas tiene el

servidor:

Se tiene servicio de internet alambrico o

inhalambrico:

Que ancho de banda tiene el servicio de

internet dentro de la institución:
 Que cubrimiento (en porcentaje) de
internet tiene la institución:

Con que sistemas de alamacenamiento de

información cuenta la institución:

Que sistema operativo se maneja en la

institución y con cuantas licencias
cuéntala institución:

Defina en detalle con que equipos cuenta

para las modalidades de MRI, CT y PET.

Para las modalidades anteriores, ¿con que

licencias DICOM cuenta?

Numero de examanes de MRI realizados al

mes:

Numero de examanes de CT realizados al

mes:

Numero de examanes de PET realizados al

mes:
Cuenta con sistemas de digitalización de
imágenes ¿cuales?

Que protocolos de comunicación están

implementados en la institución:

Cual es su proyección de crecimiento del

area de imagenología para los próximos 5
años.

Cuantas estaciones de diagnostico desea

tener:

Su propósito es comprar o rentar los

equipos.

Especifique en detalle la cantidad de

profesionales encargados de las
modalidades de imagenología antes
mencionadas.

Cuantas unidades de impresión de imagen

desea tener.
 BIBLIOGRAFÍA

[1] www.elai.upm.es/spain/Investiga/GCII/personal/.../Dicom.pdf

[2]Google Health y las Historias Clínicas. Disponible en: http://farmacologiaymedicina.com/google-

health-historias-clinicas/

[3]KEYOSE ya esta aquí para gestionar nuestro historial médico. Disponible en:
http://www.genbeta.com/web/keyose-ya-esta-aqui

[4]HL7 en colombia, panorama de desarrollo en nuestro país. Portilla Fernando. Disponible en:
http://www.hl7.org.co/files/asamblea_2008Fp.pdf

[5]http://www.dcm4che.org/confluence/display/d2/dcm4che2+DICOM+Toolkit;jsessionid=0FD51F
CCC9892B885CC349E1253D3C76

[6] PACS and Imaging Informatics: Basic Principles and Applications, H. K. Huang.