divisÍÓn de ciencias bÁsicas e ingenierÍa …148.206.53.84/tesiuami/uami10860.pdf · la...
TRANSCRIPT
DIVISÍÓN DE CIENCIAS BÁSICAS E INGENIERÍA
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA
DISEÑO DE UNA BASE DE DATOS PARA LA CREACIÓN DE UNA HISTORIA CLÍNICA ELECTRÓNICA PARA LOS PACIENTES DE LA UNIDAD DE DIAGNOSTICO
CLÍNICO
Tesis que presenta el alumno: SOTO GARCÍA JOSÉ JAVIER
Con matricula :
95322924
Para la obtención del grado: LICENCIATURA EN INGENIERÍA BIOMÉDICA
Área de concentración:
Ingeniería Clínica
Lugar de realización: Hospital Médica Sur
Asesor:
______________________________ Ing. Teófila Cadena Alfaro
Diciembre 2003
1
INDICE
1. Antecedentes 1.1 Antecedentes Generales ..................................................................................................... 3
1.2 Historia Clínica Electrónica ............................................................................................... 5
1.3 Problemática del Equipo Médico ....................................................................................... 8
1.4 Sistema de Información Hospitalaria (HIS) (Heath Information System) ......................... 9
1.5 Definición de Interfase ..................................................................................................... 14
1.6 Protocolos de Comunicación............................................................................................ 14
1.7 Estandarización en Tecnologías de Información y Comunicaciones en el Área Médica 24
1.8 Estandarización en la Transmisión de Información Médica HL7(Health Level 7) ......... 26
1.9 Estandar DICOM 3.0........................................................................................................ 42
1.10 Formato PDF .................................................................................................................. 45
2. Objetivo
2.1 General ............................................................................................................................. 49
2.1 Particulares ....................................................................................................................... 49
3. Metodología
3.1 Análisis de Necesidades ................................................................................................... 49
3.2 Especificaciones Técnicas de los Equipos ...................................................................... 50
3.3 Características del Software de Cada Equipo .................................................................. 53
3.4 Implementación................................................................................................................ 54
4. RESULTADOS ....................................................................................................................... 59
5. CONCLUSIONES.................................................................................................................... 63
6. REFERENCIAS ...................................................................................................................... 64
2
1. ANTECEDENTES
1.1 Antecedentes Generales
El sector salud genera y utiliza un gran volumen de información, que es necesario aprovechar para mantener un expediente actualizado de los pacientes y obtener información estadística con fines de investigación clínica o epidemiológica, pero a pesar de ello la promoción, aceptación y uso de tecnología de la informática y comunicación se encuentra rezagado en comparación con otros sectores de la sociedad similares en cuanto a la cantidad de información que manejan, como el sector bancario. Esto es debido más que una falta de conocimiento y ventajas del uso de las tecnologías de la informática en el sector salud, a una serie de factores como son: falta de inversión en informática médica, la existencia de un mercado donde los proveedores desarrollan sus propios sistemas, los cuales no son compatibles entre sí, la falta de estándares o su lenta aplicación y la imposibilidad de los organismos normalizadores de ofrecer una perspectiva global con una estrategia clara. Actualmente se observa que en el área de la salud se ha presentado un incremento en el uso de las tecnologías de informática y comunicaciones, pero a pesar de ello mucha información se sigue manejando de forma manual como las historias clínicas que a la fecha se siguen manejando en papel. Esto es debido a que los sistemas de información se utilizan principalmente en tareas administrativas o en los servicios de laboratorio, imagen o farmacia dejando a un lado los servicios de atención clínica. Es difícil desarrollar un sistema de información que pueda satisfacer todas las necesidades de información de un organismo tan complejo como un hospital. Si agregamos que dentro de las Instituciones de salud no ha existido una política global en cuanto a la implementación y uso de las tecnologías de la informática, se obtiene como resultado la proliferación de múltiples sistemas de información dentro de los departamentos del hospital, los cuales no son compatibles entre si, pueden contener información duplicada, en muchos casos de forma inconsistente y no es posible disponer de ella en cualquier punto del hospital. La mayoría de estos sistemas son adecuados para la realización de las tareas especificas del área, pero son inadecuados cuando se habla de una integración de información y de sistema hospitalario. La atención a los pacientes, cada día requiere compartir responsabilidades entre las distintas áreas dentro de los hospitales e incluso con otras organizaciones. Esto acarrea que los profesionales de la salud necesiten compartir e intercambiar la información clínica sobre los pacientes, históricamente esto sé llevado a cabo por medio de cartas, informes de altas y hojas de resultados en papel.
3
Se invierte mucho tempo extrayendo la información de los documentos asociados al paciente para preparar tales informes.
Estos procesos basados en papel son a menudo demasiados lentos para
proporcionar la información necesaria cuando se debe tomar decisiones críticas. Se puede afirmar que la imposibilidad actual de compartir la información clínica sobre los pacientes entre sistemas y organizaciones automáticamente es una de las mayores trabas en el sector salud para proporcionar una atención integral.
El uso compartido de la información clínica entre los profesionales u organismos de salud depende, de forma crucial, del uso de tecnologías de la informática y de las comunicaciones.
Figura 1. Necesidades de intercambio de información en los sistemas de salud
Aunque la necesidad de las historias clínicas electrónicas como herramientas
para proporcionar una atención médica integral es reconocida, los progresos realizados han sido lentos. Se han expuesto muchas razones del porqué de esta situación: la complejidad y diversidad de la información médica, la necesidad de usar una gran cantidad de términos descriptivos, la seguridad y la confidencialidad, el tener que cubrir las necesidades de todos los implicados en el sector salud: Médicos, pacientes, investigadores, administradores, etc., además de contemplar las peculiaridades funcionales, departamentales, lingüísticas y personales.
4
1.2 Historia Clínica Electrónica
Existe en la literatura una gran confusión de términos relacionados con los registros médicos almacenados en soporte electrónico. Cuatro de los más usuales son: las historias médicas automatizadas, historias médicas computarizadas, historias médicas electrónicas e historias clínicas electrónicas.
• Las historias médicas automatizadas son las que se encuentra actualmente en la mayoría de los hospitales. Utilizan el papel como soporte junto con un conjunto de sistemas informáticos departamentales aislados basados en arquitecturas tradicionales.
• Las historias médicas computarizadas se construyen escaneando los
documentos basados en papel.
• Las historias médicas electrónicas comprenden un conjunto de sistemas de información departamentales pertenecientes a una única organización sanitaria que se encuentran integrados con un alto nivel de interoperabilidad.
• Las historias clínicas electrónicas incluyen a las historias médicas electrónicas
junto con enlaces multi-organización (regional, nacional, internacional). Por tanto requiere un sistema universal de identificación de pacientes y una infraestructura y tecnología para el intercambio de información.
La siguiente figura contiene un gráfico temporal donde se muestra la posible evolución de todos estos tipos de registros médicos en soporte informático.
Figura 2. Posible evolución temporal de los diversos tipos de registros clínicos en soporte informático. Fuente: Medical Record Institute.
5
La historia médica/clínica electrónica tiene diversas ventajas sobre las historias
tradicionales basadas en papel, podemos enumerar las más importantes:
• Toda la información sobre un paciente esta disponibles en varios lugares al mismo tiempo.
• La información está disponible rápidamente lo cual es muy importante en
urgencias.
• Permite presentar los datos de diversas formas: cronológicamente, por tema, origen de datos, etc.
• Permite la reutilización de resultados de pruebas diagnósticas previas lo cual
puede evitar su duplicación.
• Facilita la investigación médica Por otro lado también tiene algunas desventajas:
• Existe riesgo de pérdida de integridad o disponibilidad debido a fallas técnicas.
• Requiere un mayor desembolso inicial en hardware, software y formación del personal.
• La seguridad y confidencialidad de los datos son aspectos críticos especialmente
cuando el sistema no sé administra adecuadamente.
• El personal puede presentar resistencia a las nuevas formas de introducción de datos (barrera del teclado).
El desarrollo de sistemas de historias clínicas electrónicas ha sido bastante lento a pesar de los grandes avances tecnológicos en las tecnologías de la información que han surgido en los últimos años, como por ejemplo: Internet, CORBA (CORBAmed), Java o XML, los cuales son adecuados para el desarrollo de estos sistemas. En la introducción ya se citaron algunas razones para este subdesarrollo tales como: la falta de inversión en tecnologías de la información, la necesidad de proteger pasadas inversiones, la complejidad intrínseca de la información sanitaria en cuanto a variedad y estructura, la ausencia de una planificación global y la falta de estándares.
6
Arquitectura de la Historia Clínica Electrónica
Las historias clínicas electrónicas contiene información clínica sobre los pacientes, esta información debe estar estructurada de alguna manera, de forma que la información pueda ser manipulada o procesada por un sistema informático. Esta estructura debe ser adecuada para el proceso de atención a la salud así como para otros posibles usos de la información (investigación, enseñanza, auditoria, aspectos legales, etc.). Por esto que uno de los aspectos más importantes a la hora de desarrollar sistemas de historia clínicas (médicas) electrónicas es cómo organizar la información clínica.
La arquitectura de la historia clínica electrónica modela las características
genéricas aplicables a cualquier anotación en una historia clínica independientemente de la organización (primaria, especializada, etc.). La arquitectura debe proporcionar principalmente mecanismos para capturar fielmente el significado original de la información y asegurar que la historia clínica sea comunicable. Por comunicable entendemos la comunicación de partes de la historia clínica entre diversos profesionales que trabajan en distintos lugares sea segura y relevante, y que por tanto se salvaguarde el significado original de los datos. Por último, cabe destacar que una arquitectura no dicta que información clínica debe registrarse ni como debe implementarse el sistema información que administre las historias clínicas.
Un aspecto clave que cualquier arquitectura de historia clínica debe definir es el
contexto que debe acompañar a cualquier anotación en la historia clínica. Básicamente una anotación consiste de tres tipos de mecanismos:
• Contenedores: encabezamientos, etiquetas, etc.
• Contenido: texto libre, medidas, sistemas de codificación, imágenes, listas de opciones, etc.
• Contexto: cualquier tipo de información que influya en la interpretación de una
anotación. El contexto es básico para capturar fielmente el significado original de la información y preservar la integridad médico-legal. Ejemplos de información de contexto son: sujeto de atención (paciente, feto, familiar, etc.), fecha y hora de la atención y su registro, control de versión, énfasis y presentación, médico responsable, enlaces con otras anotaciones, certeza, estado, unidades de medida, precisión, etc.
Uno de los mayores problemas es determinar que información de contexto debe ser almacenada y transmitida con la información de forma que se salvaguarde su significado original. [1]
7
1.3 Problemática del Equipo Médico
Anteriormente se utilizaba el termino de instrumento médico para definir dispositivos de mano utilizados por los médicos en la observación de pacientes, examinación de órganos, realización de mediciones sencillas de varios parámetros fisiológicos.
En la actualidad los médicos requieren mediciones detalladas y exactas de un
gran numero de parámetros fisiológicos además de poder manejar y procesar la información para poder realizar un diagnostico y una prescripción de procedimientos complicados para su tratamiento. Como resultado, el número de instrumentos y dispositivos médicos han crecido de unos cientos a más de 10,000 hoy en día y la complejidad ha crecido al mismo ritmo.
El campo de la instrumentación médica no es nuevo. Muchos instrumentos se
desarrollaron en fechas tempranas como el siglo XlX; un ejemplo es el electrocardiógrafo. El progreso de los equipos médicos fue muy lento, en un principio se limitaban a obtener datos de parámetros fisiológicos, su funcionamiento era analógico se basaba en tubos de vacío, el despliegue de resultados era en formato de papel.
Después de la segunda guerra mundial, época en la cual hubo un gran avance
tecnológico, aparecen los transistores y posteriormente los amplificadores, el desarrollo de equipo médico aumento, sin embargo seguían siendo analógicos.
A mediados de la década de los setenta, con la creación y desarrollo de
microprocesadores, se inicia una nueva etapa, estos equipos eran híbridos una combinación entre analógico y digital en su parte electrónica, eran sistemas cerrados cuya única forma de comunicación era el despliegue de datos, esto era a través de displays o en formato de papel.
A principios de los 80’ se tiene la primera generación de equipo médico que
cuenta con microprocesadores de propósito general, eran sistemas cerrados, sin embargo algunos comenzaban a presentar dispositivos de comunicación, su función era enviar el estado interno del sistema. Posteriormente aparece una nueva generación de equipo médico los cuales cuentan con microprocesadores de propósito especifico sin embargo eran sistemas semicerrados. A finales de los 80’ se implementa el puerto serial RS 232. como sistema de comunicación de datos, esto permitió que los equipos médicos se conectaran con computadores y por medio de software realizar la adquisición de los datos en forma digital.
La ultima generación de equipo médico permite la realización de instrumentación
virtual que es el reducir al mínimo los componentes analógicos, aumentado la capacidad de conversión analógica – digital, todo el procesamiento de la información es 100% digital, esta generación se centra en el desarrollo de plataformas de software para aplicaciones, así como el de interfases.
8
1.4 Sistema de Información Hospitalaria (HIS) (Heath Information System)
Los Sistemas de Información Hospitalaria (HIS) han sido desarrollados para
mejorar el manejo de la información dentro de los hospitales y así elevar la calidad de la atención médica. A partir de la década de los 60s se ha venido desarrollando los sistemas de información hospitalaria por distintos especialistas.
La implementación de un HIS comprende un avance sobre los sistemas de uso
habitual, esto significa que lo supera en posibilidades de funciones y rendimiento, pero también comprende nuevas responsabilidades y exigencias. Estos sistemas se basan en las posibilidades que ofrecen los actuales lenguajes de programación para el desarrollo de Software de alto rendimiento(1)
Exigencias Responsabilidades
1.Medir los resultados de los procesamientos realizados. 1.Privacidad
2.Obtener información epidemiológica. 2.Seguridad
3.Realizar análisis estadístico. 3.Protección
4.Permitir una práctica Clínica basada en la evidencia. 4.Integridad
5.Manejar guías y protocolos para la gestión Clínica de casos. 5.Autenticidad
6.Manejar un sistema de alerta en pantalla. 6.Confidencialidad
7.Manejar Cuadros de lista y selección y botones buscadores.
8.Poseer un discriminador de órdenes duplicadas.
9.Tener capacidad para manejar opciones de elección alternativas.
10.Tener capacidad de realizar estudio de resultados cuestionables.
Cuadro 1: Exigencias que debe cumplir un HIS
9
Características Técnicas de un HIS Un HIS puede implementarse a partir de un conjunto mínimo de módulos, debe cumplir con lo siguiente:
• Trabajar sobre un hardware lo suficientemente rápido que permita un correcto funcionamiento en tiempos y formas, según las especificaciones de uso y rendimiento que se esperan del HIS.
• Trabajar sobre un sistema operativo que permita correr el sistema en tiempo y forma, según las especificaciones de uso y rendimiento.
• Ambos, Hardware y Sistema Operativo, deben poseer la posibilidad de adaptación a los cambios derivados del desarrollo y crecimiento del hospital.
• El Lenguaje de programación y el administrador de la base de datos deben tener el nivel y flexibilidad adecuada para permitir todos los cambios y adaptaciones necesarias que se impongan.
Para que un HIS pueda implementarse en forma adecuada es necesario establecer políticas, estrategias y normas adecuadas tanto para el desarrollo como para la organización y/o formación del personal involucrado. Campos y Registros
Los campos para el manejo de datos primarios se crean a partir de las normas para la creación de una historia clínica del paciente. Esta información estructura la base de datos del HIS.
10
REQUERIMIENTOS GENERALES REQUERIMIENTOS ESPECIFICOS
1.Requerimientos para el manejo de Archivos. 1.Requerimientos específicos para desarrollo
de un Sistema Local.
2.Requerimientos para la Interfaz del usuario. 2.Requerimientos específicos para las
"Herramientas del Cuidado Diario".
3.Requerimientos en el rendimiento en las
operaciones de Entrada / Salida y Captura de
Datos.
3.Requerimientos específicos para un Sistema
de manejo de medicamentos.
4.Requerimientos del cumplimiento legal
incluyendo el secreto.
4.Requerimientos específicos para un Módulo
de referencias / resultados.
5.Requerimientos de Seguridad.
6.Requerimientos referentes a la
Comunicación.
7.Requerimientos de la Documentación del
Sistema.
Cuadro 2: Requerimientos del HIS
Funcionamiento Estructural Básico
• El Sistema de Información Hospitalaria deberá permitir un conjunto de información multidisciplinaria, en el cual todo el personal que lo requiera puede buscar o recuperar información, así como guardar y registrar información del paciente.
11
• La información deberá poder almacenarse en diferentes bases de datos
localmente distribuidas, pero al mismo tiempo deberá ser posible recopilar y presentar los datos en un registro único de paciente.
• El sistema deberá permitir que varias personas accedan de forma simultánea al
registro electrónico del paciente.
• Todas las funciones del sistema deberían diseñarse según las normas oficiales vigentes, basarse en las tendencias internacionales respecto al diseño del HIS
• Todo el sistema debe superar los resultados obtenidos usando los sistemas habituales de registro y procesamiento de datos e información.
• Modulo de registro de pacientes debería permitir el anexo de información sobre una anterior y una nueva cita del paciente.
• El sistema deberá poder manejar cuestiones tales como citas fuera de turno, la administración de medicamentos fuera de horario, alergias, etc.
• El sistema deberá permitir el manejo en pantalla de ventanas de “observaciones”
• Las notas de registros de pacientes deben estructurase en forma tal que permitan la búsqueda por términos y palabras
• La búsqueda de palabras y notas en el sistema, debe ser rápida y funcional, y estar asociada con el tiempo que dispone el usuario para esta área.
• La búsqueda de palabras y notas en el sistema, deberá ser posible basándose en una recopilación con sentido lógico.
• Debe ser posible la búsqueda de la información basándose en la orientación del
problema. [2]
12
Figura 3. Diagrama de Sistema de Información Hospitalaria (HIS)
13
1.5 Definición de Interfase
Un conjunto de componentes que permiten la comunicación y la interacción entre dos sistemas de diferente naturaleza, ya sea entre un usuario y una computadora, entre dos computadores, o una computadora y un equipo. Una de las características primordiales es que las interfaces son relativamente pequeñas, por lo que no son estorbosas o necesiten un espacio especial y por lo tanto tengan un manejo sencillo.
1.6 Protocolos de Comunicación
Definición
Es un conjunto de reglas y normas que hacen posible el intercambio eficaz y seguro de información entre computadoras y otros dispositivos.
Los protocolos también son necesarios para definir el formato en que se enviarán los datos, así como para controlar el tráfico de la red. Modelo ISO/OSI
OSI: Open System Interconnections: fue creado a partir del año 1978, con el fin de conseguir la definición de un conjunto de normas que permitieran interconectar diferentes equipos, permitiendo la comunicación entre ellos. El modelo OSI fue aprobado en 1983.
Un sistema abierto debe cumplir las normas que facilitan la interconexión tanto a
nivel hardware como software con otros sistemas (arquitecturas distintas). Este modelo define los servicios y los protocolos que permiten la comunicación,
dividiéndolos en 7 niveles diferentes, en el que cada nivel se encarga de problemas de distinta naturaleza interrelacionándose con los niveles contiguos, de forma que cada nivel se sustrae de los problemas que los niveles inferiores solucionan para dar solución a un nuevo problema, que se separa de los niveles superiores.
14
NIVELES FUNCIÓN
Aplicación Semántica de los datos
Presentación Representación de los datos
Sesión Diálogo ordenado
Transporte Extremo a extremo
Red Encaminamiento
Enlace Punto a punto
Físico Eléctrico / Mecánico
Cuadro 3: Nivel y Función del Modelo ISO/OSI
Se puede decir que la filosofía de este modelo se basa en la idea de dividir un
problema grande (la comunicación en sí), en varios problemas pequeños, independizando cada problema del resto. Es un método parecido a las cadenas de montaje de las fábricas; los niveles implementan a un grupo de operarios de una cadena, y cada nivel, al igual que en la cadena de montaje, supone que los niveles anteriores han solucionado unos problemas de los que él no se ocupara para dar respuesta a unos nuevos problemas, que no afectaran los niveles superiores. Este modelo considera 7 capas: Capa 7: La capa de aplicación:
La capa de aplicación es la capa del modelo OSI más cercana al usuario, y está relacionada con las funciones de mas alto nivel que proporcionan soporte a las aplicaciones o actividades del sistema, suministrando servicios de red a las aplicaciones del usuario y definiendo los protocolos usados por las aplicaciones individuales. Es el medio por el cual los procesos de aplicación de usuario acceden al entorno OSI.
Su función principal es proporcionar los procedimientos precisos que permitan a los usuarios ejecutar los comandos relativos a sus propias aplicaciones.
Los procesos de las aplicaciones se comunican entre sí por medio de las entidades de aplicación asociadas, estando éstas controladas por protocolos de aplicación, y utilizando los servicios del nivel de presentación.
Difiere de las demás capas debido a que no proporciona servicios a ninguna otra capa OSI, sino solamente a aplicaciones que se encuentran fuera del modelo OSI. La capa de aplicación establece la disponibilidad de los diversos elementos que deben participar en la comunicación, sincroniza las aplicaciones que cooperan entre sí y
15
establece acuerdos sobre los procedimientos de recuperación de errores y control de la integridad de los datos.
Algunos ejemplos de procesos de aplicación son:
• Programas de hojas de cálculo.
• Programas de procesamiento de texto.
• Transferencia de archivos (ftp).
• Login remoto (rlogin, telnet).
• Correo electrónico (mail - smtp).
• Páginas web (http).
Capa 6: La capa de presentación:
La capa de presentación proporciona sus servicios a la capa de aplicación, garantizando que la información que envía la capa de aplicación de un sistema pueda ser entendida y utilizada por la capa de aplicación de otro, estableciendo el contexto sintáctico del diálogo. Su tarea principal es aislar a las capas inferiores del formato de los datos de la aplicación, transformando los formatos particulares (ASCII, EBCDIC, etc.) en un formato común de red.
Es también la responsable de la obtención y de la liberalización de la conexión de sesión cuando existan varias alternativas disponibles.
Por ello, de ser necesario, la capa de presentación realiza las siguientes operaciones:
• Traducir entre varios formatos de datos utilizando un formato común, estableciendo la sintaxis y la semántica de la información transmitida. Para ello convierte los datos desde el formato local al estándar de red y viceversa.
• Definir la estructura de los datos a transmitir. Por ejemplo, en el caso de un
acceso a la base de datos, definir el orden de transmisión y la estructura de los registros.
• Definir el código a usar para representar una cadena de caracteres (ASCII,
EBCDIC, etc.).
• Dar formato a la información para visualizarla o imprimirla.
• Aplicar a los datos procesos criptográficos.
16
Capa 5: La capa de sesión:
La capa de sesión proporciona sus servicios a la capa de presentación, proporcionando el medio necesario para que las entidades de presentación en cooperación organicen y sincronicen su diálogo y procedan al intercambio de datos. Sus principales funciones son:
• Establece, administra y finaliza las sesiones entre dos “hosts”(computadoras dedicadas a ejecutar aplicaciones) que se están comunicando.
• Si por algún motivo una sesión falla por cualquier causa ajena al usuario, esta
capa restaura la sesión a partir de un punto seguro y sin perdida de datos o si esto no es posible termina la sesión de una manera ordenada revisando y recuperando todas sus funciones, evitando problemas en sistemas de intercambio.
• Sincroniza el diálogo entre las capas de presentación de los dos hosts y
administra el intercambio de datos, estableciendo las reglas o protocolos para él dialogo entre maquinas y así poder regular quien habla y por cuanto tiempo o si hablan en forma alterna, es decir, las reglas del dialogo que son acordadas.
• Ofrece disposiciones para una eficiente transferencia de datos, clase de servicio
y un registro de excepciones acerca de los problemas de la capa de sesión, presentación y aplicación.
• Manejo de tokens. Los tokens son objetos abstractos y únicos que se usan para
controlar las acciones de los participantes en la comunicación.
• Hacer checkpoints, que son puntos de revisión en la transferencia de datos. Capa 4: La capa de transporte:
La capa de transporte proporciona sus servicios a la capa de sesión, efectuando
la transferencia de datos entre dos entidades de sesión. Para ello segmenta los datos originados en el host emisor y los reensambla en una corriente de datos dentro del sistema del host receptor.
El límite entre la capa de sesión y la capa de transporte puede imaginarse como
el límite entre los protocolos de capa de medios y los protocolos de capa de host. Mientras que las capas de aplicación, presentación y sesión están relacionadas con aspectos de las aplicaciones, las tres capas inferiores se encargan del transporte de datos. Además, esta capa es la primera que se comunica directamente con su par de destino, ya que la comunicación de las capas anteriores es de tipo máquina a máquina.
17
La capa de transporte intenta suministrar un servicio de transporte de datos que
aísla las capas superiores de los detalles de implementación del transporte, liberándolas de luchar por conseguir una transferencia de datos segura y económica.
Específicamente, temas como la confiabilidad del transporte entre dos hosts es
responsabilidad de la capa de transporte. Al proporcionar un servicio de comunicaciones, la capa de transporte establece, mantiene y termina adecuadamente los circuitos virtuales. Al proporcionar un servicio confiable, se utilizan dispositivos de detección y recuperación de errores de transporte.
Se conocen con el nombre de circuitos virtuales a las conexiones que se
establecen dentro de una subred, y en ellos no hay la necesidad de tener que elegir una ruta nueva para cada paquete, ya que cuando se inicia la conexión se determina una ruta de la fuente al destino, ruta que es usada para todo el tráfico posterior.
Podemos resumir las funciones de la capa de transporte en los siguientes puntos:
• Controla la interacción entre procesos usuarios.
• Incluye controles de integración entre usuarios de la red para prevenir perdidas o
doble procesamiento de transmisiones.
• Controla el flujo de transacciones y direccionamiento de maquinas a procesos de usuario.
• Asegura que se reciban todos los datos y en el orden adecuado, realizando un
control de extremo a extremo. • Acepta los datos del nivel de sesión, fragmentándolos en unidades más
pequeñas, llamadas segmentos, en caso necesario los pasa al nivel de red.
• Realiza funciones de control y numeración de unidades de información, fragmentación y reensamblaje de mensajes.
• Se encarga de garantizar la transferencia de información a través de la sub-red.
18
Capa 3: La capa de red:
La capa de red proporciona sus servicios a la capa de transporte, siendo una
capa compleja que proporciona conectividad y selección de ruta entre dos sistemas de hosts que pueden estar ubicados en redes geográficamente distintas. También se ocupa de aspectos de contabilidad de paquetes.
Es la responsable de las funciones de conmutación y encaminamiento de la
información, proporcionando los procedimientos precisos necesarios para el intercambio de datos entre el origen y el destino, por lo que es necesario que conozca la topología de la red, con objeto de determinar la ruta más adecuada.
Podemos resumir las funciones de la capa de red en los siguientes puntos:
• Divide los mensajes de la capa de transporte en unidades más complejas, denominadas paquetes y los ensambla al final.
• Debe conocer la topología de la subred y tomar en cuenta que la fuente y el
destino de la información se encuentran en redes distintas.
• Para ello, se encarga de encaminar la información a través de la sub-red, mirando las direcciones del paquete para determinar los métodos de conmutación y enrutamiento, dirige los paquetes de la fuente al destino a través de ruteadores intermedios.
• Envía los paquetes de nodo a nodo usando ya sea un circuito virtual o como
datagramas.
• Debe controlar la congestión de la subred. En esta capa es donde trabajan los routers. Capa 2: La capa de enlace de datos:
La capa de enlace proporciona sus servicios a la capa de red, suministrando un tránsito de datos confiable a través de un enlace físico. Al hacerlo, la capa de enlace de datos se ocupa del direccionamiento físico (comparado con el lógico), la topología de red, el acceso a la red, la notificación de errores, formación y entrega ordenada de tramas y control de flujo. Por lo tanto, su principal misión es convertir el medio de transmisión en un medio libre de errores de cualquier tipo.
19
Sus principales funciones son:
• Establecer los medios necesarios para una comunicación confiable y eficiente entre dos máquinas en red.
• Agrega una secuencia especial de bits al principio y al final del flujo inicial de bits
de los paquetes, estructurando este flujo bajo un formato predefinido llamado trama o marco.
• Suelen ser de unos cientos de bytes.
• Sincroniza el envío de las tramas, transfiriéndolas de una forma confiable libre de
errores. Para detectar y controlar los errores se añaden bits de paridad, se usan CRC (Códigos Cíclicos Redundantes) y envío de acuses de recibo positivos y negativos, y para evitar tramas repetidas se usan números de secuencia en ellas.
• Envía los paquetes de nodo a nodo usando ya sea un circuito virtual o como
datagramas.
• Controla la congestión de la red.
• Regula la velocidad de tráfico de datos.
• Controla el flujo de tramas mediante protocolos que prohíben que el remitente envíe tramas sin la autorización explícita del receptor, sincronizando así su emisión y recepción.
• Se encarga de la de secuencia, de enlace lógico y de acceso al medio (soportes
físicos de la red). Capa 1: La capa física:
La misión principal de esta capa es transmitir bits por un canal de comunicación, de manera que cuanto envíe el emisor llegue sin alteración al receptor.
La capa física proporciona sus servicios a la capa de enlace de datos, definiendo las especificaciones eléctricas, mecánicas, de procedimiento y funcionales para activar, mantener y desactivar el enlace físico entre sistemas finales, relacionando la agrupación de circuitos físicos a través de los cuales los bits son movidos.
Las características tales como niveles de voltaje, temporización de cambios de voltaje, velocidad de datos físicos, distancias de transmisión máxima, conectores físicos y otros atributos similares se definen a través de las especificaciones de la capa física.
20
Sus principales funciones las podemos resumir en:
• Definir las características físicas (componentes y conectores mecánicos) y eléctricas (niveles de tensión).
• Definir las características funcionales de la interfaz (establecimiento,
mantenimiento y liberación del enlace físico).
• Transmitir el flujo de bits a través del medio. No existe estructura alguna.
• Maneja voltajes y pulsos eléctricos.
• Especificar cables, conectores y componentes de interfaz con el medio de transmisión, polos en un enchufe, etc.
• Garantizar la conexión, pero no la fiabilidad de ésta.
Esta capa solamente reconoce bits individuales, no reconoce caracteres ni tramas multicaracter. TCP/IP Transfer Communication Protocol / Internet Protocol
El TCP/IP es un conjunto de protocolos de comunicación, es decir de
convenciones particulares, creadas para permitir la colaboración y la partición de recursos entre más computadoras conectadas entre sí en la que está definida como red o network. Internet es en absoluto la más grande entre todas las redes existentes, debido a que logra conectar entre sí computadoras personales y redes de menor amplitud en todo el mundo. Sobre Internet, de hecho, se puede encontrar en conexión los servidores de instituciones del gobierno, militares, universidades y empresas privadas.
Lo que permite a máquinas tan distintas por hardware y por prestaciones,
comunicar entre sí de manera casi transparente, es él, TCP/IP, el cual constituye un tipo de 'lenguaje universal' comprendido y utilizado por todas las máquinas que cooperan en red.
Vamos a empezar con algunas definiciones de base. El nombre más apropiado para indicar este conjunto de protocolos, es Internet protocol suite, es decir colección de protocolos de Internet. El TCP y el IP son dos protocolos que pertenecen a esta colección.
21
Puesto que éstos son también los protocolos más conocidos, ha entrado en el uso común llamar TCP/IP a toda la familia, aunque en algunas ocasiones una generalización parecida pueda resultar un error. Como quiera que se llame, el TCP/IP representa una familia de protocolos, proveen a la gestión de las funciones de bajo nivel, que son necesarias para la mayoría de las aplicaciones. El TCP y el IP pertenecen a los protocolos de bajo nivel.
Sobre esta base, se desarrollan otros protocolos que administran funciones
particulares, como la transferencia de ficheros, el envío del correo electrónico, la conexión remota, el control de los usuarios que se han conectado a la red en un momento específico, con dividir impresoras y de programas aplicativos y algo más.
Todo esto está generalmente simplificado en un modelo cliente / servidor, en el
cual el servidor se identifica con el procesador que proporciona un servicio específico, a través de la red, por ejemplo él sitio FTP de VOL FTP (es un servidor de ficheros y de informaciones sobre cómo utilizarlos de la manera mejor) y en el cual el término cliente se identifica con el procesador que explota este servicio, aunque con la palabra cliente incluya también aquellos programas que uno utiliza para tener acceso a estos mismos servicios (por ejemplo el Tiber y el Netscape son dos clientes típicos para tener acceso a las páginas del WWW). El TCP/IP es un conjunto de protocolos 'a capas' o, si se prefiere, 'a niveles'.
Para entender qué significa todo lo anterior pongamos un ejemplo sencillo.
Imaginemos que se tiene que enviar correo a través de Internet. Lo primero que se necesita es definir un protocolo específico para el correo, o sea, un conjunto de reglas unívocamente reconocidas por todos las computadoras conectados en red.
Dicho protocolo tendrá la tarea de capturar la carta que hay que enviar, añadirle el emisor y el destinatario y enviarla a quien corresponda. Esto último es la tarea del protocolo específico de gestión del correo, que podría ser comparado al de una persona a la que un amigo muy ocupado le deja una carta y ella se encarga de ponerla en el sobre, escribir los datos de expedición y entregarla al correo.
Evidentemente, si sólo existiese esta figura la carta se quedaría eternamente en
el buzón sin que nadie se preocupase de hacerla llegar a su destino. Sin embargo, nuestro amigo muy ocupado tendría suerte ya que existe una
camioneta del servicio de correos que dos veces al día vacía el buzón y transporta las cartas que allí encuentra a un lugar donde serán clasificadas y diferenciadas; allí su preciosísima carta será cuidada y protegida hasta que llegue al buzón del destinatario.
22
Para continuar con el paralelismo del ejemplo, diremos que el TCP/IP representa
el sistema de transporte de Internet. En particular, el TCP se preocupa de 'empaquetar' todos los datos que le son suministrados por los protocolos de nivel superior; es posible que los subdivida en más partes si resultaron demasiado largos para un solo envío en red; asimismo recuerda lo que ha sido enviado, se acuerda de volver a enviarlo en el caso en que se hubiera perdido y controla que todo se realice de forma transparente para el usuario.
Ya que este tipo de operaciones es de uso general y es necesario tanto para enviar correo como para enviar ficheros u otras cosas, se ha pensado en hacer un protocolo propio, que pueda ser utilizado por muchos otros. Es precisamente por este motivo por lo que hemos definido protocolo de bajo nivel.
El TCP, sin embargo, no es el protocolo de nivel más bajo desde el momento en que éste utiliza el IP para realizar determinadas acciones. De hecho, a pesar de que el TCP sea muy utilizado, existen protocolos que prefieren no usarlo y que para funcionar sólo necesitan las funciones que puede ofrecer incluso el más humilde IP.
Este tipo de organización 'a capas' permite una gran eficiencia y un menor gasto de recursos.
Para terminar con un ejemplo, el envío de un mensaje de correo electrónico a través de Internet utiliza un sistema compuesto por cuatro capas:
Un protocolo de alto nivel específico para el correo 2. El protocolo TCP que es utilizado también por otros protocolos de alto nivel 3. El protocolo IP que se ocupa de la específica tarea de tomar los paquetes y enviarles a su destino 4. El protocolo del hardware específico, que se utiliza para la transmisión y la recepción de los datos
En este punto nos parece claro el motivo por el que el conjunto de los protocolos de Internet es llamado genéricamente TCP/IP. De hecho, estos son los protocolos más utilizados y de los que sólo pueden prescindir muy pocos protocolos de un nivel más alto.
Antes de terminar esta exposición general sobre el funcionamiento del TCP/IP es
necesario introducir el concepto de datagrama (datagram), que representa cada uno de los paquetes de informaciones que es enviado a través de la red. Como ya hemos dicho antes, un conjunto de informaciones demasiado largo que es subdividido en paquetes más pequeños, precisamente llamados datagrama, que viajan individualmente en la red. Esto significa que si un fichero que se debe enviar es subdividido en 10 datagramas secuenciales, no está dicho que el cuarto llegue antes que el séptimo, desde el momento en que éste puede perderse o tomar un camino equivocado. Será una tarea de los diversos protocolos el hacer que dicho paquete sea enviado nuevamente y colocado en el correcto orden secuencial cuando llega a su destino.
23
Y ahora, diremos que a pesar de que los términos datagrama y paquete son muy a menudo utilizados como sinónimos, en realidad existe una diferencia. Mientras el datagrama es específico del TCP/IP y representa la mínima unidad lógica utilizable por los diversos protocolos, el paquete es una entidad física bien presente para quien administra una red de tipo Ethernet. En el caso, por lo demás muy frecuente, que en un paquete viaje un solo datagrama, la diferencia es sólo teórica pero existen también configuraciones específicas de hardware de red que utilizan paquetes de dimensión menor respecto a la del datagrama individual.
Entonces sucede que un datagrama se descompone en más paquetes durante el
envío a la red específica y que sea recompuesto a su llegada, de forma absolutamente transparente respecto al mismo datagrama que... 'no se da cuenta' de haber sido descompuesto y luego recompuesto.
Es evidente cómo en dicha situación los términos paquete y datagrama no
coinciden. Es una buena medida, por tanto, acostumbrarse a utilizar el término datagrama cuando se habla del TCP/IP. [3]
1.7 Estandarización en Tecnologías de Información y Comunicaciones en el Área Médica
Los cambios en las Instituciones de Salud están produciendo una demanda creciente de la conectividad e interoperabilidad de los sistemas de información de forma que se permita la comunicación y trasferencia electrónica de datos haciéndolos disponibles donde hace falta a fin de soportar la operación de los servicios y la continuidad de la asistencia. Para ello resulta esencial promover la adopción de normas en aspectos tales como terminología, codificación, formatos, mensajes, historia clínica electrónica, registros médicos, imágenes, y protección de datos. En este contexto los trabajos de normalización representan una acción estratégica fundamental para la difusión extendida de las aplicaciones informáticas y telemáticas para la salud. El desarrollo de normas en este campo plantean una variedad de retos, tales como la adecuación de tiempos de generación y adopción al ritmo que demanda el mercado, aumento en la coordinación entre los diferentes actores y la activación del papel de las instituciones públicas. Las Normas El proceso de normalización consiste en identificar las necesidades de armonía y compatibilidad de los sectores implicados tales como fabricantes, proveedores, usuarios y autoridades, para producir un consenso sobre los elementos que constituyen la norma.
24
La normalización actúa sobre tecnología ya consolidada y está basada en la experiencia. Busca lograr un beneficio común mediante el acuerdo sobre el ordenamiento de técnicas de uso repetido. Las normas pueden ser oficiales o “de fabrica”. Una norma oficial es un documento público, elaborado por consenso, de acuerdo con un procedimiento establecido con el respaldo de un organismo reconocido.
Tradicionalmente en informática han proliferado soluciones no compatibles cerradas que han obligado a los usuarios a depender de un suministrador particular con los consiguientes problemas. También se producen situaciones donde un fabricante o grupo de ellos impulsa un conjunto de especificaciones intentando dominar un mercado y constituir un “estándar de fabrica”. Las normas oficiales ofrecen mayores garantías para el conjunto de las posibles partes interesadas. Tienen en su contra la lentitud, el costo y la complejidad del proceso. En los últimos años, el desarrollo de Internet y WWW han impulsado mecanismos alternativos más rápidos para el desarrollo de normas.
Los temas de estandarización han cobrado mayor importancia y se están volviendo más complejos con la globalización de la economía y de los mercados.
Los productos se tienen que diseñar para ser aceptados por usuarios de
múltiples países con diferentes lenguas, sistemas de valores y condiciones de trabajo.
Por ello se hace absolutamente necesario la colaboración internacional en materia de normalización. Las tareas de promoción, generación y mantenimiento de estándares requieren un gran esfuerzo de organización, involucran un gran número de expertos y llevan su tiempo.
Los principios de trabajo descansan en tres elementos característicos: consenso, visión global y carácter voluntario.
• CONSENSO: Se toma en cuenta todas las partes interesadas tales como fabricantes, vendedores, usuarios, profesionales, autoridades públicas, centros de investigación.
• VISIÓN GLOBAL: Soluciones para en todo el mundo
• CARÁCTER VOLUNTARIO: Las tareas de normalización van dirigidas a facilitar el desarrollo del mercado y, por lo tanto, deben respetar la libertad de los proveedores.
25
Perspectivas a Futuro Entre los temas planteados de cara al futuro inmediato se encuentran: la necesidad de acelerar el desarrollo de los estándares, la coordinación para optimización de recursos, y la discusión sobre el papel de las administraciones. Aunque la coordinación de los esfuerzos para el desarrollo de estándares muestra un avance importante, existen muchas lagunas y el ritmo de desarrollo de normas tiene necesidades de mejorar. Entre las razones que explican la lentitud en el desarrollo de las normas para informática y telemática dentro del área de la salud se suele identificar el carácter voluntario de la participación y la falta de recursos para asegurar la participación de agentes importantes como los usuarios. Además lleva mucho tiempo el consenso en los entornos clínicos. En este aspecto pueden jugar su papel las administraciones nacionales y la comisión de estandarización para acelerar el desarrollo de los estándares y su adopción por los servicios nacionales de salud sobre la base del beneficio público. Dentro de los mercados telemáticos en general existe un énfasis creciente para establecer mecanismos de prueba de conformidad de los requisitos especificados por los estándares. De hecho la certificación y prueba de productos, el registro de sistemas de calidad y la acreditación de laboratorios están siendo cada vez más importantes para los organismos de estandarización. Dentro del campo de las aplicaciones sanitarias será necesario prestar atención al desarrollo de estos elementos en los próximos años y fundamentalmente a la cooperación internacional. [4]
1.8 Estandarización en la Transmisión de Información Médica HL7(Health Level 7)
Introducción
El Health Level 7 (HL7) es una especificación para un estándar de intercambio de datos electrónicos en el ambiente de la atención de la salud, con especial énfasis en las comunicaciones intrahospitalarias. Es el resultado del trabajo de un Comité de proveedores de usuarios, vendedores y consultores de sistemas de aplicación al área de salud.
El hospital promedio de la actualidad posee programas instalados que se ocupan del registro de los procesos de admisión y egreso de pacientes, de registro y producción de información de laboratorio clínico, de informes de radiología y patología, de facturación y administración general entre otros.
26
A menudo estas aplicaciones han sido desarrolladas por diferentes proveedores o grupos propios, poseyendo cada producto formatos de datos altamente específicos. A medida que los hospitales van expandiéndose, las operaciones de procesamiento de información se expanden en forma acelerada, y la necesidad de compartir los datos que encierran esa información se torna crítica. El desarrollo y disponibilidad de sistemas globales de informatización hospitalaria, que solo algunos proveedores muy selectos han desarrollado hasta la fecha, mitigarían la necesidad de estándares para la transmisión externa de datos del tipo del HL7. No obstante, estos programas son todavía escasos y su implementación requiere fuertes inversiones iniciales tanto de hardware como de software, lo cual hace que sigan existiendo y desarrollándose las aplicaciones específicas de bajo costo.
Por otro lado, las instituciones hospitalarias aún son el objeto de fuertes presiones en el sentido de la adquisición o el desarrollo de aplicaciones departamentales con un criterio modular.
Fuentes características de este tipo de presiones son ciertas necesidades
departamentales de procesamiento de información no adecuadamente resueltas por los sistemas "globales". Otra fuente característica de presiones es la necesidad de desarrollar un sistema finalmente global a través de sucesivas etapas, atendiendo a necesidades departamentales según un esquema de prioridades, y no a efectuar una sola adquisición, brusca y revolucionaria.
La necesidad del desarrollo de estándares que sirvan de base a interfaces entre sistemas surge a partir de la aparición de la tecnología de redes para la integración de programas de aplicación al área de salud que residen en computadoras que funcionan y técnicamente son diferentes. Dado que estos programas han sido desarrollados como respuesta a la estructura y a las demandas del mercado, más que a un enfoque lógico de sistemas, a menudo son enormemente inadecuados y con particularidades bastante marcadas. Lograr su integración suele requerir enorme cantidad de horas de programación especificas al sitio y al ambiente de redes.
Esto ocurre a expensas del comprador y/o el vendedor, e impide al personal
involucrado dedicarse a iniciativas más productivas como el desarrollo de nuevos módulos o productos.
La cantidad de sistemas a vincular aumenta en forma exponencial la cantidad de
tiempo invertido en el desarrollo de interfaces, en tanto que el apego a un estándar solo requiere del esfuerzo de su desarrollo por única vez.
27
Antecedentes
El Comité del HL7 (Health Level 7 Working Group), comenzó su actividad en Marzo de 1987, a raíz de una conferencia organizada por el Hospital de la Universidad de Pennsylvania, a propósito de la problemática de los estándares en salud. Su objetivo es la estandarización del formato y del protocolo para el intercambio de ciertos conjuntos de datos entre sistemas de aplicación al área de salud. El Grupo de Trabajo (GT) se reúne aproximadamente cada 4 meses en diferentes lugares de los EE.UU., y ya se han formado grupos nacionales en otros países, que actualmente incluyen Australia, Alemania, Japón, Holanda y Nueva Zelanda. El mecanismo de trabajo del GT consta básicamente de la definición de grupos de datos relevantes a determinados procesos que forman parte de un sistema de atención de la salud, de la determinación de un formato específico para los mismos, y de la producción de un documento final del estándar, que es votado y aprobado por los miembros del GT. Hasta la fecha el GT a presentado su solicitud para transformarse en un Comité de Estándares Acreditado ante el ANSI (American National Standards Institute). Así mismo, el GT participa en el Panel de Estándares de Información de la Salud (Health Information Standards Planning Panel -HISPP) del ANSI.
El HL7 ha experimentado un gran crecimiento como organización en los últimos años. Actualmente posee 800 miembros en diferentes categorías y reúne a mas de 250-300 miembros y no-miembros en sus reuniones tri-anuales. El GT ha documentado la existencia de más de 170 organizaciones vinculadas a la provisión de servicios de salud que han implementado sus interfaces entre sistemas sobre la base del estándar HL7. Se sospecha, además, que existen numerosas instituciones que lo utilizan sin ser miembros oficiales del Grupo, ya que no es obligatorio pertenecer al GT para utilizarlo.
El término "Nivel 7" se refiere al más alto de los niveles del modelo OSI (Open Systems Interconnection) de la ISO (International Standards Organization). Esto no implica que el HL7 conforme específicamente a determinados elementos constitutivos del séptimo nivel del OSI. De hecho, el HL7 no especifica un conjunto de especificaciones propias del OSI para los niveles 1 al 6. En cambio, si conforma específicamente a la definición conceptual de un enlace de aplicación en lo que hace estrictamente al nivel 7 del modelo OSI.
En el modelo OSI, las funciones que hacen a la comunicación entre sistemas, tanto en materia de hardware como de software, se dividen en siete niveles.
En el nivel 7 (siete), a los cuales se refiere específicamente el HL7, se definen
los datos a ser intercambiados, el timing de dichos intercambios, y la comunicación de determinados mensajes de error específicos de las aplicaciones que participan del intercambio
28
Objetivo
En su estado actual el HL7 se ocupa de las interfaces entre sistemas que emiten o reciben mensajes de registro, admisión, transferencia y alta de pacientes, pedidos de información al sistema, ordenes, resultados, observaciones clínicas, facturación, y actualización de información de archivos maestros. El HL7 no asume ninguna arquitectura en particular con respecto a la ubicación de los datos dentro de la aplicación, aunque está diseñado para dar soporte tanto a un sistema central de atención de pacientes, como a un ambiente más distribuido donde las aplicaciones departamentales son las bases de los datos. Considerando la enorme cantidad de aplicaciones que actualmente existen en el campo de la salud, así como la variedad de ambientes en los cuales se efectúan procesos de atención a la salud, resulta evidente que existen muchas interfaces adicionales que se beneficiarían con el desarrollo de estándares. Las elegidas, citadas anteriormente, fueron consideradas prioritarias por los participantes del proceso de elaboración del estándar. Otras áreas que ya han sido identificadas son las siguientes:
• Apoyo a la toma de decisiones;
• Aplicaciones de enfermería; • Aplicaciones de departamentos de servicios auxiliares; • Historias clínicas computarizadas; • Necesidades de información externas al ámbito hospitalario.
Formato General del HL7
El HL7 es una especificación de formato de mensajes entre aplicaciones dirigidas al soporte informático de los procesos de atención de la salud.
El formato general de los mensajes consiste de campos de datos de longitud variable, separados por caracteres especiales, según reglas específicas de codificación.
Los campos de datos se combinan para formar agrupamientos lógicos
denominados segmentos, los cuales a su vez están separados entre sí por caracteres específicos. Atento a lo expuesto, un mensaje del HL7 podría ilustrarse de la siguiente manera:
29
SEG
SEG
SEG
SEG
SEG
SEG
SEG
CD CD CD
CD
CD
CD
CD
CD
CD CD CD
CD
CD
CD
CD
CD
CD
Expresado en términos simples y exhibido como un texto, un mensaje se
compone de diversas líneas, cada una de las cuales representa un segmento. Esto es así en virtud de que el carácter separador de segmento es el retorno de carro (un carácter no visible que en término de texto señala un cambio de renglón al siguiente).
En su versión actual, el HL7 codifica 27 tipos de mensaje, cada uno de ellos
referido a un proceso especifico del conjunto de los que forman el proceso general de la atención de la salud.
ack.- acuse de recibo general adt.- admisión, transferencia y alta bar.- agregar a o cambiar factura dft.- detalle de transacción financiera dsr.- exhibir mensaje de respuesta mcf.- acuse de recibo diferido mfd.- acuse de recibo diferido para aplicación sobre actualización de archivo maestro mfk.- acuse de recibo de archivo maestro mfn.- notificación de archivo maestro mfq.- interrogación a archivo maestro mfr.- respuesta de archivo maestro orf.- resultado solicitado de observación orm.- mensaje de orden orr.- mensaje de resultado de orden oru.- resultado no solicitado de observación qry.- mensaje de interrogación ras.- información administrativa de farmacia rde.- información sobre orden de farmacia rds.- información sobre preparación de farmacia rgv.- información sobre dosis de farmacia rra.- informe de administración de farmacia rrd.- informe histórico de preparaciones de farmacia rre.- informe histórico de ordenes codificadas de farmacia rrg.- informe histórico de entregas de farmacia rxo.- orden de farmacia udm.- mensaje de exhibición no solicitado
30
Tal como se desprende de la descripción de cada uno de los mensajes, los mismos representan información pertinente a procesos hospitalarios determinados y específicos. En lo que sigue, y utilizando como ejemplo un mensaje tipo ADT (admisión, transferencia y alta), describiremos la estructuración de un mensaje del HL7.
Estructura de los Mensajes HL7 (Mensajes ADT como ejemplo)
El conjunto de mensajes ADT transmite datos que contienen información demográfica sobre pacientes, así como información sobre los eventos de reasignación, admisión, derivación interna y externa, alta y visitas de los mismos. Dado que virtualmente todos los programas de aplicación asimilados a una red hospitalaria requieren información sobre pacientes, esta variedad de transacciones es una de las más frecuentemente observadas. Generalmente, la información que identifica al paciente y a los motivos de su acceso al sistema es ingresada a través de un sistema específico de registro, y trasladada desde allí a otros sistemas: de historia clínica, de registro de servicios auxiliares - laboratorio, radiología. Etc.-, de facturación, y otros.
A01 admisión de paciente A02 transferencia de paciente A03 alta de paciente A04 registro de paciente A05 pre-admisión de paciente A06 transferencia de internado a ambulatorio A07 transferencia de ambulatorio a internado A08 actualización de información de paciente A09 paciente saliendo A10 paciente arribando A11 cancelación de admisión de paciente A12 cancelación de transferencia de paciente A13 cancelación de alta de paciente A14 admisión de paciente pendiente A15 transferencia de paciente pendiente A16 alta de paciente pendiente A17 intercambio de pacientes A18 unión de información de paciente A19 consulta sobre paciente A20 actualización de estado de cama A21 paciente sale en "salida con permiso" A22 paciente retorna de "salida con permiso" A23 borrar registro de paciente A24 enlace de información sobre paciente A25 cancelación de alta de paciente pendiente A26 cancelación de transferencia de paciente pendiente A27 cancelación de admisión de paciente pendiente A28 agregar información sobre persona
31
A29 borrar información sobre persona A30 unir información sobre persona A31 actualizar información sobre persona A32 cancelar paciente arribando A33 cancelar paciente saliendo A34 enlace de información sobre paciente - solo para identificación (ID) A35 enlace de información sobre paciente - solo para número de cuenta A36 enlace de información sobre paciente - solo para ID y número de cuenta A37 anular enlace de información sobre paciente
El conjunto de mensajes ADT codifica 37 eventos diferentes. Uno de los mensajes más simples, cual es el de admisión de un paciente (A01), consta de cuatro segmentos obligatorios y 13 segmentos opcionales. Entre los últimos, 10 pueden repetirse.
Los segmentos encerrados por llaves ( [ ] ) indican su condición de opcionales,
en tanto que aquellos rodeados por llaves son pasibles de ser repetidos. En el caso específico de un mensaje ADT de la variedad A01, los segmentos obligatorios corresponden al encabezado del mensaje (MSH), al codificador de evento (EVN), al segmento que contiene información sobre el paciente (PID) y al que codifica los datos correspondientes al proceso de visita (PV1).
Los campos constitutivos de los segmentos de existencia obligada en un
mensaje ADT de la variedad A01. La composición de los segmentos no es específica para cada mensaje, sino que
se mantiene a través de todo el estándar. Por lo tanto, la descripción de los segmentos que sigue es válida para cualquier mensaje en donde el segmento específico aparezca.
El segmento de encabezamiento del mensaje (MSH -Message Header-)
El segmento de encabezamiento del mensaje define el propósito del mismo, a su remitente y destinatario, y a los detalles de sintaxis de la totalidad del mensaje. Al igual que la totalidad de los segmentos que componen el HL7, en MSH se identifica como tal por presentar el código de tres caracteres que lo identifica al principio del mismo.
32
1. - Separador de campo (carácter codificador) 2. - Caracteres de codificación 3. - Aplicación que envía el mensaje 4. - Sitio que envía el mensaje 5. - Aplicación a la cual va dirigido el mensaje 6. - Sitio al cual va dirigido el mensaje 7. - Fecha y hora del mensaje 8. - Información de seguridad 9. - Tipo de mensaje 10. - Código de identificación del mensaje 11. - Identificación de tipo de procesamiento 12. - Versión de HL7 13. - Número secuencial de mensaje 14. - Puntero de continuación 15. - Tipo de acuse de recibo de aceptación 16. - Tipo de acuse de recibo de aplicación 17. - Código de país.
A.- Separador de campo.
Identifica al carácter que indicará el final de un campo y comienzo de otro. El valor recomendado es la barra vertical ( ' | ' ). Por lo tanto el primer elemento de nuestro mensaje A01 contendrá al carácter que el resto del mensaje deberá identificar como separador de campo:
MSH| B.- Caracteres de codificación.
Este campo tiene una extensión precisa de 4 espacios, cada uno de los cuales contendrá, respectivamente, • El carácter separador de componentes de campo: muchos campos contienen varios
elementos. Así, por ejemplo, el campo que identifica al paciente por su nombre contiene varios elementos (apellido, nombre, etc.). Cada uno de esos elementos está separado por el "carácter separador de componentes". El valor recomendado es '^'.
• El carácter codificador de segmentos repetitivos: en ocasiones un mensaje puede
contener segmentos repetidos. Tal es el caso del segmento que contiene los diagnósticos realizados a un paciente, que puede ocurrir en número de uno o más. El valor recomendado es '~'.
33
• El carácter de escape: especialmente utilizado en campos de texto, precediendo un código que señala una característica especial de una porción del texto. Así, si en un texto aparece en un punto determinado dos caracteres de escape '\' que encierran una 'H', significará que a partir de allí el texto deberá ser exhibido por el sistema en formato resaltado (color o negrita). La aparición del nuevo código "\N\" indicará e final del texto resaltado. El valor recomendado es ('\').
• El carácter separador de subcomponentes de campo: separa los elementos que a
su vez puede contener un componente de un campo. El valor recomendado es '&'. Utilizando los valores recomendados nuestro mensaje adquiriría la siguiente forma:
MSH| ^~\&| C.- Aplicación que envía el mensaje.
Contiene una cadena de caracteres (generalmente un código o sigla) que identifica al programa que envía el mensaje. Así, en nuestro ejemplo podríamos llamar al programa de admisión de pacientes "APHI" (“Admisión de Pacientes del Hospital Informatizado"), con lo cual nuestro mensaje quedaría ahora así constituido:
MSH| ^~\&|APHI|
D.- Sitio que envía el mensaje.
Contiene una cadena de caracteres (también generalmente un código o sigla) que identifica al sitio de la institución que envía el mensaje. En nuestro ejemplo el sitio lógico sería la recepción del Hospital, a la cual bautizaríamos "REC-H1". La cadena de caracteres tomaría entonces esta forma:
MSH| ^~\&|APHI| REC-H1|
E. Aplicación a la cual va dirigido el mensaje.
Contiene la cadena de caracteres que identifica al programa destinatario del mensaje. En nuestro hospital, un mensaje de admisión podría estar dirigido al programa que almacena los resultados producidos por el Laboratorio de Química Clínica, que desea tener registrado a todo paciente que pase por el hospital. El programa se llamaría "INFOLAB", y daría a nuestro mensaje la siguiente forma:
MSH| ^~\&|APHI| REC-H1|INFOLAB|
34
F. Sitio al cual va dirigido el mensaje.
Contiene la cadena de caracteres que identifica al sitio destinatario del mensaje. Dado que en nuestro ejemplo el mensaje iba dirigido a un programa de laboratorio, es ese el sitio al cual va dirigido. Lo llamaremos "LABAC" y dará al mensaje un nuevo campo:
MSH| ^~\&|APHI| REC-H1|INFOLAB| LABAC|
G.- Fecha y hora del mensaje.
Contiene la fecha y hora de creación del mensaje, conforme al formato especificado por el HL7 (AAAAMMDDHHMMSS). Dando como resultado la siguiente forma:
MSH| ^~\&|APHI| REC-H1|INFOLAB| LABAC|19940101130243|
H.- Información de seguridad.
Es un campo aún no especificado que se anticipa implementaría información de seguridad para el mensaje. Dado que aún no esta implementado dejará esta campo vacío:
MSH| ^~\&|APHI| REC-H1|INFOLAB| LABAC|19940101130243||
I.- Tipo de mensaje. Contiene el código que identifica al tipo y/o variedad de mensaje. En los casos en
que contiene tipo y variedad, estos componentes están separados por su separador respectivo, identificado más arriba. En nuestro caso estamos construyendo un mensaje ADT de la variedad A01, por lo cual nuestro mensaje pasará a:
MSH| ^~\&|APHI| REC-H1|INFOLAB| LABAC|19940101130243||ADT^A01|
J.- Código de identificación del mensaje.
Representado por un número o código que identifica inequívocamente al
mensaje. Este campo es utilizado por el sistema destinatario del mensaje para elaborar la respuesta. En nuestro caso el sistema identificaría nuestro primer mensaje de la siguiente manera:
MSH| ^~\&|APHI| REC-H1|INFOLAB| LABAC|19940101130243||ADT^A01|0000001|
35
K.- Identificación de tipo de procesamiento.
Identifica mediante un tipo de procesamiento que deberá aplicarse al mensaje, conforme a una tabla definida por el HL7. Para no entrar en el detalle, agregaremos simplemente 'P' al mensaje: MSH| ^~\&|APHI| REC-H1|INFOLAB| LABAC|19940101130243||ADT^A01|0000001| L.- Versión del HL7
Contiene un identificador de la versión del HL7 que esta siendo utilizado. En
nuestro caso, la mas reciente: “2.2”
MSH|^~\&|APHI|REC-H1|INFOLAB|LABAC|19940101130243||ADT^A01|0000001|2.2| M.- Puntero de continuación.
Define el identificador de una continuación del mensaje. Dado que nosotros estamos elaborando un mensaje único, dejaremos esta campo libre:
MSH|^~\&|APHI|REC-H1|INFOLAB|ABAC|19940101130243||ADT^A01|0000001|2.2|| N.- Tipo de acuse de recibo de aceptación
Codifica las condiciones bajo las cuales los acuses de recibo de aceptación del
sistema destinatario son requeridas. Dado que se impone solo para algunos tipos de acuse de recibo, mantendremos este campo en blanco:
MSH|^~\&|APHI| RECH1|INFOLAB|ABAC|19940101130243||ADT^A01|0000001|2.2||| Ñ.- Tipo de acuse de recibo de aplicación
Codificador de las condiciones para recibir acuses de recibo en respuesta al mensaje. También es especifico para ciertos tipos de acuse de recibo, por lo cual también lo ignoraremos:
MSH|^~\&|APHI|REC-1|INFOLAB|LABAC|19940101130243||ADT^A01|0000001|2.2||||
36
O.- Código de país. Identifica al país mediante un código de tres letras especificado por la ISO. La
Argentina se identifica como ARG: MSH|^~\&|APHI|RECH1|INFOLAB|LABAC|19940101130243||ADT^A01|0000001|2.2||||ARG|
La línea así constituida culmina el segmento MSH de nuestro mensaje. Los segmentos están separados mediante un carácter de retorno de carro, que en un texto no aparecerá, sino que se traducirá en el pasaje al renglón siguiente. Conforme a esto, el próximo segmento de nuestro mensaje ADT aparecerá de esa manera.
El segmento de Evento del mensaje (EVN -Event-).
El segmento de Evento del mensaje, indicado por la aparición de EVN al comienzo del segmento, comunica información sobre un evento particular en un proceso de atención de la salud referenciado por el mensaje y siempre señala una variedad de alguno de los mensajes del HL7, detallados mas arriban.
1. - Código del tipo de evento
2. - Fecha y hora del evento
3. - Fecha y hora de un evento planeado
4. - Codificador de la razón del evento
5. - Identificación del operador
A.- Código del tipo de evento.
Identifica al tipo de evento según una tabla predefinida por el HL7. En el caso de los mensajes ADT, corresponde a los tres caracteres que identifican a la variedad de proceso. En nuestro caso, un sencillo proceso de admisión de paciente, corresponde A01, lo cual da a nuestro mensaje la siguiente forma: MSH|^~\&|APHI|RECH1|INFOLAB|LABAC|19940101130243||ADT^A01|0000001|2.2||||ARG|EVN|A01|
37
B.- Fecha y hora del evento.
Señala la fecha y hora en que fue generado el evento, conforme al formato especificado anteriormente. En nuestro mensaje, le da la forma: MSH|^~\&|APHI|RECH1|INFOLAB|LABAC|19940101130243||ADT^A01|0000001|2.2||||ARG|EVN|A01|19940101130102| C.- Fecha y hora de un evento planeado.
Señala la fecha y la hora de un evento planeado. Se recomienda su uso, por
ejemplo, para señalar el momento para el cual se planea el alta. En nuestro caso, que procesa la admisión de una paciente para ser operado, el mensaje podría así adquirir la forma: MSH|^~\&|APHI|RECH1|INFOLAB|LABAC|19940101130243||ADT^A01|0000001|2.2||||ARG|EVN|A01|19940101130102|19940110| D.- Codificador de la razón del evento.
Describe la razón por la cual se generó el evento conforme a una tabla definida por el usuario. Nosotros podríamos codificar la razón “indicación médica” como “01”, con lo cual nuestro mensaje pasaría a:
MSH|^~\&|APHI|RECH1|INFOLAB|LABAC|19940101130243||ADT^A01|0000001|2.2||||ARG|EVN|A01|19940101130102|19940110|01| E.- Identificación del operador.
Contiene un código que identifica a la persona que generó el evento. En nuestro
caso, codificaríamos a la Srta. Recepcionista NN como "SRNN", dando a nuestro mensaje la forma:
MSH|^~\&|APHI|RECH1|INFOLAB|LABAC|19940101130243||ADT^A01|0000001|2.2||||ARG|EVN|A01|19940101130102|19940110|01|SRNN| El campo E marca el final del segmento EVN.
38
El segmento de Identificación de Paciente del mensaje (PID-Patient Identification).
El segmento de referencia contiene información demográfica acerca del paciente, y es utilizada virtualmente por todos los sistemas de una red hospitalaria para transmitir la información que permite identificar al mismo.
No describiremos en detalle los campos dado que muchos son autoexplicativos.
Solo interesa destacar que algunos contienen varios componentes, delimitados por sus respectivos separadores. También importa señalar que si bien el número de campos es alto, solo son obligatorios en el mensaje los campos 3 y 5 (de identificación interna, por ejemplo: número de HC- y nombre del paciente).
1. - Identificador de segmentos repetidos
2. - Identificación externa del paciente
3. - Identificación interna del paciente
4. - Identificación alternativa del paciente
5. - Nombre del paciente
6. - Apellido de la madre
7. - Fecha de nacimiento
8. - Sexo
9. - Alias del paciente
10. - Raza
11. - Domicilio del paciente
12. - Código de país
13. - Número de teléfono del hogar del paciente
14. - Número de teléfono del empleo del paciente
15. - Lenguaje nativo del paciente
16. - Estado civil
17. - Religión
18. - Número de cuenta del paciente
19. - Número de seguridad social del paciente
20. - Número de licencia de conductor del paciente
21. - Identificador de la madre
22. - Grupo étnico
39
El segmento de Visita de Paciente del mensaje (PV1 -Patient Visit-). El segmento en cuestión contiene la información referente a una o más visitas
del paciente a la institución.
CODIGO DESCRIPCION 1 Identificador de segmentos repetidos 2 Clase de paciente 3 Localización asignada al paciente 4 Tipo de admisión 5 Número de pre-admisión 6 Localización previa del paciente 7 Médico de cabecera 8 Médico que deriva 9 Médico consultor 10 Servicio hospitalario a recibir por el paciente 11 Localización temporaria 12 Indicador de exámenes de pre-admisión 13 Indicador de re-admisión 14 Lugar de admisión del paciente 15 Estado ambulatorio 16 Indicador VIP 17 Médico que recibe 18 Tipo de paciente 19 Número de visita 20 Clase financiera 21 Indicador de escala de precio 22 Código de cortesía 23 Índice de crédito 24 Código de contrato 25 Fecha de comienzo del contrato 26 Monto del contrato 27 Duración del contrato 28 Código de interés
40
29 Indicador de transferencia a cuenta observada 30 Fecha de transferencia a cuenta observada 31 Código de agencia de cuenta observada 32 Suma transferida a cuenta observada 33 Suma obtenida del garante de cuenta observada 34 Indicador de cuenta discontinuada 35 Fecha de cuenta discontinuada 36 Estado al alta 37 Lugar de destino del paciente al alta 38 Tipo de dieta 39 Sitio que provee el servicio 40 Estado de la cama 41 Estado de la cuenta 42 Localización en espera 43 Localización temporaria previa 44 Fecha y hora de admisión 45 Fecha y hora de alta 46 Estado actual de la cuenta 47 Cargo total 48 Ajustes totales 49 Pagos totales 50 Número de identificación de visita (alternativo)
En el caso de este segmento, solo son obligatorios los campos 2 y 3, que indican
la clase de paciente (de emergencia, externo, interno, obstétrico, etc.) y el sitio asignado (habitación / cama, consultorio, etc.).
Como habrá podido observarse, el mensaje tiene una estructura sumamente
sencilla en términos electrónicos, y es fácilmente transportable e interpretable por virtualmente cualquier sistema o aplicación. La forma en la cual se transmita no esta específicamente indicada en el estándar y deberá ser acordada entre los sitios emisor y receptor del mensaje.
Podrá variar, como ya se ha dicho, desde un sistema de red OSI-compatible
hasta un sencillo cable RS-232 conectando dos máquinas entre sí. El HL7 solo busca ofrecer un formato de datos que todos los sistemas puedan conocer, evitando así la necesidad de trabajar sobre una nueva interfase toda vez que una nueva aplicación se sume a los recursos informáticos compartidos por un sistema de atención de la salud. [5]
41
1.9 Estándar DICOM 3.0
DICOM (Digital Imaging and Communications in Medicine) es el estándar
industrial para transferencia de imágenes radiológicas e información médica entre computadoras. DICOM permite la comunicación digital entre equipos de diagnostico, terapéuticos y sistemas de diferentes fabricantes.
El estándar DICOM 3.0 (1992) evolucionó de versiones anteriores desarrolladas
por ACR(American College of Radiology) y NEMA(National Electrical Manufactures Association).Con fondos de RSNA (Radiological Society of North America) el Instituto Mallinckrodt de Radiología desarrolló el software que fue el primero en implementar y establecer las especificaciones técnicas del estándar DICOM.
Los objetivos iniciales fueron trabajar con los diferentes problemas de
compatibilidad, con el fin de interfazar los ambientes propietarios de las diferentes modalidades de imágenes.
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.
42
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.
Con el tiempo que se dió 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 cómputo, sin embargo, el estándar no ofrecía ningú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 de envió de mensajes.
Después de tres años de esfuerzo, sé dió a conocer la versión ACR / NEMA
llamado 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.
43
• 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 interfazar 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).
Para cumplir eficientemente con los requerimientos operativos, cada uno de los
componentes del sistema debe especificarse utilizando el estándar DICOM. El objetivo es: evitar problemas de comunicación originados por errores de interpretación en la información. Especificaciones para comunicación en red.
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.
44
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.
DICOM establece dos tipos de servicios básicos: Usuario de servicios de clase
(Service Class User: SCU) que juegan las reglas de cliente y Proveedor de servicios de clase (Service Class Provider: SCP) que juegan las reglas de servidor. En cada caso, las reglas son definidas durante la asociación. El establecimiento de asociación corresponde a la primera fase de comunicación entre dos entidades de aplicación compatibles con DICOM, que una vez lograda, negocia los tipos de objetos a intercambiar y la forma de codificarlos. [6]
1.10 Formato PDF
El formato PDF (Formato de Documento Portátil) es el estándar de fábrica para la distribución e intercambio seguro y fiable de documentos y formularios electrónicos.
Este es un formato de archivo universal que mantiene las fuentes, imágenes, gráficos y apariencia de cualquier documento de origen, independientemente de la aplicación y plataforma utilizadas para crearlo. Los archivos PDF de Adobe® son compactos y completos; se pueden compartir, ver e imprimir con el software gratuito Adobe Acrobat Reader®.
Se puede convertir cualquier archivo al formato PDF de Adobe utilizando el
software Adobe Acrobat®.
45
Características del Formato
• Cualquier persona en cualquier lugar puede abrir un archivo PDF. Solo es necesario tener el software gratuito Adobe Acrobat Reader.
• Los archivos PDF son compactos, permiten la realización de búsquedas y puede accederse a ellos en cualquier momento utilizando el visualizador Acrobat Reader. Los hipervínculos interactivos hacen que sea fácil navegar por los archivos PDF.
• El formato PDF etiquetado permite la redistribución del texto para que se muestre correctamente en plataformas portátiles como los dispositivos Palm OS, Symbian y Pocket PC.
• Permiten asignar derechos de acceso especiales y pueden firmarse de forma digital.
• Los archivos PDF etiquetados contienen la información sobre su contenido y estructura lo que permite el acceso a ellos con la ayuda de lectores de pantalla.
Adobe Acrobat Adobe Acrobat® es un software de aplicación más eficaz y segura para el intercambio universal de archivos pues garantiza poder compartirlos electrónicamente, convirtiendo documentos en papel o electrónicos, o un sitio web en un archivo de formato PDF de Adobe, mostrando intacta su apariencia original (fuentes, colores, formato y gráficos) y permitiendo su impresión en cualquier soporte. Sus características son:
• Creación de archivos fiables en formato PDF de Adobe
• Permite una mayor rapidez en la revisión de documentos
• Protección de los documentos confidenciales
Cabe destacar que el software Adobe Acrobat® es el creador de archivos con formato PDF y permite realizar la conversión de cualquier formato a PDF. Sin embargo existe el Adobe Acrobat Reader que es solo un visualizador de archivos con formato PDF. [7]
46
1.11 Antecedentes Particulares En la Unidad de Diagnostico Clínico (UDC), tiene como ayudar a conservar la
salud desarrollando un examen clínico preventivo identificando los factores de riesgo para las diferentes enfermedades. La administración de la información de los pacientes de la unidad se realiza de forma ineficiente debido a que el proceso de la información esta formado por múltiples etapas, como se muestra en el siguiente flujograma.
Paciente
1
ECG, Prueba de Esfuerzo,Audiometría, Espirometría, Imagen y Laboratorio
Médico Internista (Interrogatorio y
Auscultación)
Transcripción
Archivo Recepción
2
3
4
5
Paciente
Recepción de la
Unidad de Diagnostico
1.- Al paciente se le entrega un cuestionario en formato de papel el cual deberá entregar el día de su cita. 2.- El día de la cita el paciente entrega su cuestionario llenado y pasa a realizarse los diferentes estudios. 3.- El cuestionario así como los resultados de los estudios son entregados al médico internista quien revisa la toda la información. 4.- El médico hace un diagnostico junto con una serie de recomendaciones que son grabadas en una cinta magnética. La cinta magnética junto con los resultados de los estudios y el cuestionario se integran en un expediente el cual es llevado al área de transcripción en donde personal administrativo realizara la captura del diagnostico y de las recomendaciones. La información capturada se imprime y las impresiones son llevadas con el médico internista quien deberá revisar toda la información capturada. Si la información es correcta el médico firma los documentos y se llevan a transcripción y se colocan en un fólder junto con los resultados de los estudios. Si la información es incorrecta el médico realiza las correcciones y la regresa al área de transcripción para que realicen las correcciones marcadas y después de que el personal administrativo corrige la información, esta es enviada al médico para su revisión, este proceso se repite hasta que la información capturada sea la correcta. 5.- Una vez que la información es firmada el personal del área de transcripción envía una copia de la información al archivo y los originales se entregan a la recepción donde el paciente recibe el resultado del check up, él diagnostico y las recomendaciones todo esto en formato de papel.
47
El proceso que debe seguir el paciente para la realización de sus estudios va muy ligado al proceso de la información y se muestra en el siguiente flujograma.
1.- En su primer visita el paciente solicita el check up y se le hace entrega de un cuestionario en formato de papel así como los recipientes para la recolección de muestras, los cuales deberá entregar el día en que se realicen los estudios, y se le dan las instrucciones al paciente así como la fecha.
2.- El día de sus estudios el paciente pasa a los vestidores para cambiarse de ropa, posteriormente pasa al cubículo de toma de muestra sanguínea y pasa las diferentes áreas donde se le realizarán los estudios.
1
2
Toma de Muestras
Vestidores
Recepción de la Unidadde Diagnostico Clínico
Paciente
3.- Después de realizarle todos los estudios, el paciente pasa al consultorio del médico internista quien hace un interrogatorio y auscultación al paciente 4.- Al terminar su cita con el médico internista, el paciente pasa nuevamente a los vestidores para cambiarse de ropa y se retira del hospital, posteriormente se le entregaran los resultados de sus estudios así como él diagnostico y las recomendaciones hechas por el internista
Prueba de esfuerzo
ECG Audiometría Espirometría Imagen
Vestidores
3
Oftalmología Nutriología
Médico internista (Interrogatorio y
auscultación)
Salida
La información proviene de diferentes medios como cuestionarios, notas
médicas, equipos de diagnósticos médico, clínicos
48
2. OBJETIVO
2.1 General
Diseño de una base de datos para la creación de una Historia Clínica Electrónica
para los Pacientes de la Unidad de Diagnostico Clínico.
2.1 Particulares
• Realizar las interfases entre el equipo médico y una red de computo que será
administrada por una base de datos.
• La interfase obtendrá de cada equipo los archivos de los registros de cada
paciente para ser enviados a la base de datos por medio de la red.
• Los archivos deben integrarse a la historia clínica de cada paciente en la base
de datos.
2 METODOLOGÍA
3.1 Análisis de Necesidades
Se requiere que los resultados de los diferentes estudios como son:
Electrocardiografía, Audiometría, Prueba de Esfuerzo y Espirometría se incorporen a una base de datos por medio de una red, dichos resultados deben ser obtenidos de forma directa del equipo de diagnostico a través de una interfase. Los resultados deben manejarse como archivos individuales por paciente y deben cumplir con las siguientes características:
49
• El formato del archivo debe ser tal que se pueda mostrar en cualquier computadora sin la necesidad de tener instalado el software especializado del equipo de diagnóstico, solo es necesario que se cuente con un software básico no muy especializado como puede ser Word, Excel o Acrobat Reader.
• El tamaño del archivo debe ser manejable, del orden de los Kilobytes.
• El archivo solo debe ser de lectura.
Los componentes de este expediente son:
• Antecedentes patológicos y familiares
• Audiometría
• ECG
• Espirometría
• Laboratorio
• Prueba de Esfuerzo
• Resultados de Imagen
3.2 Especificaciones Técnicas de los Equipos
• Audiómetro.
Es un equipo generador de tonos puros. Cada tono puede ser generado a
una intensidad que va desde 0 dB hasta 110dB.El decibel (dB) corresponde a una medida de presión sonora y que equivale en el cero a 0.0002 dinas por cm2 a una frecuencia de 100 ciclos por segundo; por lo que 0 dB no significa ausencia de sonido sino que es una medida promediada y significa el menor estimulo que en determinada frecuencia un oído normal debería escuchar.
El equipo entrega tonos puros desde 128Hz hasta los 8 KHz que son las
frecuencias perceptibles para el oído humano. Cada tono puro se entrega por vía aérea y por vía ósea a cada oído, y se determina el umbral auditivo por cada vía en las distintas frecuencias. El umbral auditivo corresponde a la menor intensidad de sonido que se debe aplicar para ser escuchado el 50% de las veces en una determinada frecuencia. Lo normal es que esa intensidad fluctúe entre 0 y 20 dB.
50
El resultado de la audiometría se anota en un gráfico llamado “audiograma”
en que la horizontal corresponde a las frecuencias medidas en Hz y la vertical a la intensidad de sonido entregado en dB.
Las características del sistema de la computadora son:
o Windows 98’ o 120 MB en RAM o Disco duro de 20 GB o Puerto Serial (COM) o Puerto Paralelo (LPT) o Sin tarjeta de Red. o Procesador Genuine Intel x 86 Family 6 Model 8 Steeping 6[13]
• Banda de Esfuerzo
Es un equipo que cuenta con una banda sin fin y un módulo de registro electrocardiográfico para doce derivaciones. Sirve para realizar la prueba de esfuerzo, que básicamente es un ECG que se realiza mientras se efectúa un esfuerzo físico. Esta prueba sirve para detectar enfermedades significativas de las arterias coronarias, evaluación de pacientes con arritmias, capacidad física, circulación en extremidades inferiores, presión arterial y la respuesta del corazón en actividad física.
o Windows NT 4.00
o 256 MB en RAM
o Disco Duro de 40 GB
o Puerto Serial (COM)
o Puerto Paralelo (LPT)
o Tarjeta de Red
o Procesador Genuine Intel x 86 Family 15 Model 1 Steeping 2[14]
51
• Electrocardiógrafo
El electrocardiógrafo permite registrar la actividad eléctrica cardiaca a partir
de una serie de electrodos conectados en la superficie de cuerpo del paciente. La señal es amplificada y enviada a un sistema de procesamiento para que posteriormente se realice un registro gráfico en papel.
Se obtiene un trazo con ondas positivas y negativas que reflejan la actividad cardiaca observada desde los diferentes electrodos. Podemos definir las derivaciones del ECG como puntos de observación de los diferentes fenómenos eléctricos que ocurren en el corazón. Cada una de ellas registrará la despolarización y repolarización cardíacas. Se cuenta con doce derivaciones.
El electrocardiógrafo es un Modelo Page Writer Xli, marca Phillips. Cuenta
con:
o Una unidad de disco flexible de 3 ½ que permite el almacenamiento de los registros.
o Puerto de salida serial RS – 232 C que le permite enviar y recibir información registros ya sea por medio de un módem ó un fax módem
o Una velocidad de 2400bps. [15]
• Espirómetro
Este equipo permite realizar las pruebas de función pulmonar, en la que se
mide el volumen pulmonar, así como la eficiencia del intercambio de oxigeno en sangre.
El equipo registra la cantidad y frecuencia de aire inspirado y espirado en un
intervalo de tiempo especifico. Algunas de las mediciones del examen se obtienen de una respiración normal y en reposo, mientras que otras requieren una inhalación o exhalación forzada después de una respiración profunda.
La medición del aire inspirado y espirado se realiza a través de una boquilla
donde el paciente respira, dentro de la boquilla se encuentra un transductor térmico que consta de dos filamentos en paralelo calentados a cierta temperatura, debido al flujo de aire se producirá una diferencia de temperaturas entre filamentos, esto permitirá realizar la medición.
52
Las características del sistema de la computadora son las siguientes: o Windows 98’
o 256 MB en RAM
o Disco Duro de 40 GB
o Puerto Serial (COM)
o Puerto Paralelo (LPT)
o Tarjeta de Red
o Procesador Genuine Intel x 86 Family 15 Model 1 Steeping 2[16]
3.3 Características del Software de Cada Equipo
• Audiómetro
El nombre del software es NOAH, es una plataforma de software que
corre bajo ambiente Windows. Permite almacenar historias clínicas por medio de una base de datos, creando dos archivos, uno contiene el audiograma y otro contiene la interpretación del médico. Los archivos se encuentra codificados de tal manera que solo se pueden abrir en ‘NOAH’. [13]
• Banda de Esfuerzo
El nombre del software es Q-Stress software, este programa trabaja en Windows y Windows NT. Maneja una base de datos de todos los estudios realizados, crea un archivo por paciente. El nombre de cada archivo corresponde al nombre del paciente. El formato de este archivo es PDF. [14]
• Electrocardiógrafo El software interno del equipo permite guardar el archivo en dos
modalidades: Estándar.- se almacenan 250 muestras por segundo, contiene solamente los segmentos de formas de onda impresos en el informe auto. Se pueden almacenar hasta 100 ECG’s en un disco flexible de 3 ½. Especial.- se almacenan 500 muestras por segundo, contiene la información completa de 10 segundos para todas las derivaciones. Se pueden almacenar hasta 35 ECG’s en un disco flexible de 3 ½.
53
El programa crea un archivo por estudio y permite enviar o transmitir ECG’s a otro electrocardiógrafo Xli, a estaciones de trabajo de ECG’s o a sistemas de gestión de ECG’s. [15]
• Espirómetro
El nombre del software es VMAX, diseñado para usarse en plataforma de Windows, este programa maneja su propia base de datos de todos los estudios realizados y para ello crea un archivo por paciente, por seguridad los nombres y el contenido de los archivos se encuentra codificados de tal manera que solo se pueden abrir en ‘ VMAX ‘. [16]
3.4 Implementación
En el caso del electrocardiógrafo este no contaba con una PC, por lo que fue
necesario realizar la comunicación entre el equipo y la una computadora. Para ello se necesitaba crear un software de interfase, por lo que era necesario saber cual es el protocolo de comunicación del equipo, se extrajo información del puerto serial por medio de un programa de comunicación serial, sin embargo la forma de los datos no tenía coherencia ya que no contábamos con la información del protocolo, por tal motivo se decidió realizar la adquisición del software que permitiera la interfase.
El nombre del software es ECG Manager® este programa permite la comunicación entre el electrocardiógrafo y una PC, la comunicación se lleva a cabo por medio de un módem externo a una velocidad de 2400 bps. El ‘ECG Manager’ permite la visualización de los registros, el almacenamiento de los estudios en una base de datos interna y permite el ordenamiento de los registros ya sea por fecha, formato, nombre o ID. En el despliegue del registro en la computadora se muestran diferentes datos como son:
• Fecha. • Datos personales del paciente. • ID. • Usuario. • Frecuencia. • Amplitud de las ondas. • Interpretación.
54
Permite realizar modificaciones en los registros antes mencionados y almacenar
dichos cambios.
Sin embargo los archivos de los registros se encuentran codificados haciendo imposible poder ver el contenido en otra computadora que no cuente con el ECG Manager. Por lo que se realizo la conversión a formato PDF, esto se realizo por medio del programa Adobe Acrobat, este software permite la conversión de cualquier tipo de formato a PDF. Al instalar Adobe Acrobat en una PC, este crea una carpeta de impresora llamada “Adobe PDF Writer en LPT1”, cuando queremos realizar la conversión de formato solo se necesita abrir el archivo deseado desde su programa de origen y se manda a imprimir, seleccionando como impresora “Adobe PDF Writer en LPT1”, al enviar la impresión aparecerá una nueva ventana (conversión) donde se le asignara nombre al archivo en formato PDF y se indica la dirección en la cual se desea guardar. En nuestro caso las tres primeras letras corresponderán a una etiqueta para indicar que es un electrocardiograma (ECG), seguido de un guión bajo para finalizar con las iniciales del paciente, por ejemplo para un paciente con el nombre Cubillas Martínez Raymundo el nombre de su archivo en PDF seria: ECG_CMR. La dirección en la cual se va guardar el archivo será la dirección del disco duro donde se encuentre la base de datos de la Unidad de Diagnostico Clínico. Para el audiómetro y el espirómetro que manejan un formato codificado, por lo se aplico la conversión a formato PDF utilizando el mismo procedimiento. El equipo para la prueba de esfuerzo proporciona los registros de los pacientes en formato PDF por lo que en este equipo no fue necesario realizar una conversión.
El proceso de conversión de formato dependerá del programa del equipo por lo que para cada estudio será diferente.
55
Proceso de Conversión de Formato Para el Audiómetro 1) Realizar las pruebas de audiometría 2) En el menú principal del programa escoja la opción de NOAH 3) Ir a la opción de imprimir y escoger la opción “Informe del Cliente”, aparecerá una
pantalla de selección de impresora. 4) Seleccione la impresora Adobe PDF writer en LPT1 y oprima el botón de aceptar,
esto abrirá la “ventana de conversión” a formato PDF 5) En la “ventana de conversión” ingrese el nuevo nombre del archivo, las primeras tres
letras son la etiqueta ‘ AUG’ que indica que el estudio es de audiometría y que este archivo es el audiograma, a continuación se pone un guión bajo y por ultimo las iniciales del paciente. Quedando de la siguiente manera: AUG_xxx.
6) Oprima el botón de red y seleccione la unidad de disco duro donde se encuentra la
base de datos, busque la carpeta con el nombre de “ Audiometrías ”, selecciónela y oprima el botón de aceptar.
7) En la pantalla principal oprima el icono de “Informe”, se abrirá la “ventana del
informe” 8) En el menú principal seleccione la opción de NOAH y elija imprimir, se abrirá una
nueva pantalla donde se seleccionara la impresora. 9) Seleccione la impresora Adobe PDF writer en LPT1 y oprima el botón de aceptar,
esto abrirá la “ventana de conversión” a formato PDF. 10) En la “ventana de conversión” ingrese nuevo nombre del archivo, las tres primeras
letras son la etiqueta “AUI” que indica que el estudio es de audiometría y que el archivo es la interpretación, a continuación se coloca un guión bajo y por ultimo las iniciales del paciente. Quedando de la siguiente manera: ‘AUI_xxx’.
11) Oprima el botón de red y seleccione la unidad de disco duro donde se encuentra la
base de datos, busque la carpeta con el nombre de “ audiometrías ”, selecciónela y oprima el botón de aceptar.
12) Guarde los resultados originales en la computadora.
56
Proceso de conversión de Formato para el Electrocardiógrafo 1) Realizar el estudio de electrocardiografía, el equipo mandara automáticamente el
registro a la computadora. 2) En la computadora abra el programa ECG Manager, en el menú principal oprima el
icono de recepción de ECG’s, con esto aparecerá en la pantalla principal el nombre del paciente actual.
3) Seleccione el registro del paciente y haga doble clic, aparecerá el registro
electrocardiográfico. 4) En el menú oprima el icono de la impresora, con el cual se abrirá la “ventana de
conversión” de formato. 5) En la “ventana de conversión” ingrese el nombre del archivo, las primeras tres
letras son la etiqueta “ECG” que indica que el estudio es un electrocardiograma, a continuación se pone un guión bajo y por ultimo las iniciales del paciente. Quedando de la siguiente manera: ‘ECG_xxx’.
6) Oprima el botón de red y seleccione la unidad de disco duro donde se encuentra la
base de datos, busque la carpeta con el nombre de “ ECG’s ”, selecciónela y oprima el botón de aceptar.
7) Guarde los resultados originales en la computadora.
57
Proceso de conversión de Formato para el Espirómetro 1) Realizar el estudio de espirometría 2) En el menú principal elegir la opción de “reportes” y seleccionar “reporte final” 3) En el menú principal seleccione la opción de “printer”, esto abrirá la “ventana de
selección” de impresoras 4) En la ventana de selección elija la impresora Adobe PDF writer en LPT1 y oprima
el botón de aceptar, esto abrirá la “ventana de conversión” a formato PDF. 5) En la “ventana de conversión” ingrese el nuevo nombre del archivó, las primeras
tres letras son la etiqueta “ESP” que indica que el estudio es de espirometría, a continuación se pone un guión bajo y por ultimo las iniciales del paciente. Quedando de la siguiente manera: ‘ESP_xxx’.
6) Oprima el botón de red y seleccione la unidad de disco duro donde se encuentra la
base de datos, busque la carpeta con el nombre de “ Espirometría ”, selecciónela y oprima el botón de aceptar.
7) Guarde los resultados originales en la computadora.
58
4. RESULTADOS
Los archivos de los resultados de los estudios de audiometría, espirometría, electrocardiografía de un formato codificado se convirtieron a un formato PDF, en la siguiente figura se muestran los archivos antes y después de la conversión
Figura 4. Iconos de Archivos Codificado y PDF
Para audiometría se producen archivos, uno corresponde a la interpretación y otro al audiograma, estos se guardan en una carpeta cuyo tamaño se encuentra alrededor de 15 KB.
Para electrocardiografía el tamaño del archivo se encuentra alrededor de los
20KB y los archivos de espirometría 10KB. Para banda de esfuerzo el tamaño del archivo se encuentra alrededor de los 70KB. Estos valores son aproximados ya que el tamaño de los archivos dependerá de las pruebas realizadas en el estudio, así como el formato seleccionado.
59
Figura 5. Archivo de Audiometría Codificado abierto con el programa Block de Notas
Figura 6. Contenido de un archivo de Audiometría en formato PDF
60
Figura 7. Archivo de ECG Codificado abierto con el programa Block de Notas
Figura 8. Contenido de un archivo de ECG en formato PDF
61
Figura 9. Archivo de Espirometría Codificado abierto con el programa Block de Notas
Figura 10. Contenido de un archivo de Espirometría en formato PDF
62
5. CONCLUSIONES
Actualmente las Instituciones de Salud manejan un gran volumen de información provenientes de diferentes áreas como: laboratorio clínico, imagen, facturación, administración, entre otras. Sin embargo el campo de la informática y de la comunicación en el área de los servicios de salud se encuentra en rezago en comparación con otros. En la actualidad este campo está en una etapa de desarrollo en sus diferentes partes como son: el diseño y planeación de nuevos dispositivos, protocolos de comunicación, estandarización de protocolos, formatos de datos dentro del área médica y la creación de plataformas de software para realizar interfases y procesamiento de datos. Al término de este proyecto, se logró la realización de una base de datos conectada en red con las computadoras de consulta y con los equipos de diagnostico, permitiendo la creación de una historia clínica electrónica de los pacientes de la unidad. Con lo que se tiene un acceso rápido, sencillo y un optimo manejo de la información, lo que se ve refleja en una mejor atención al paciente. Debido a los beneficios obtenidos en esta primera etapa del proyecto, el personal de la unidad ha generado grandes expectativas en las futuras etapas; sin embargo, para obtener el máximo de beneficios es indispensable la participación del personal, por lo que es necesario un cambio de cultura laboral ya que de forma natural, las personas presentan resistencia a los cambios. Por otra parte, las etapas futuras serán enfocadas a mejorar la interfase entre el usuario y la base de datos, cubrir las necesidades del área médica y los aspectos de seguridad, hasta lograr un sistema de información flexible que en un futuro se pueda expandir y conectar con un sistema de información hospitalaria (HIS). En el campo de la informática y de la comunicación el ingeniero biomédico tiene importante presencia y participación ya que con su formación multidisciplinaria, entiende las necesidades del área médica y con sus conocimientos de ingeniería puede dar solución a las mismas, permitiendo la optimización del manejo de la información y de los recursos.
63
6. REFERENCIAS
1. Maldonado José Alberto, Cano Cesar, Robles Montserrat, Integración de
Subsistemas de Información Hospitalarios: Aplicación del estándar de arquitectura de historia clínica informatizada, 2001. [On - Line].
http://www.seis.es/inforsalud2001/cientificas2/maldonado.htm 2. Leoncio Hugo, Cuidados Informatizados de la Salud. [On – Line]. http://www.informaticamedica.org.ar/numero6/art3.htm 3. Valera Guerrera Gilda Isabel. Transmisión de Datos en Internet. 2001. [On - Line]. http://www.monografias.com/trabajos5/datint/datint.shtml#INTRO 4. Monteagudo Peña José Luis, La estandarización en Tecnologías de la Información y
las Comunicaciones para Sanidad, 2002, [On – Line]. http://www.isciii.es/publico/drvisapi.dll?MIval=cw_usr_view_SHTML&ID=1091 5. BIOCOM, Estandarización de la Informática Médica HL7, 1988 – 2003, [On - Line].
http://www.biocom.com.ar/informatica_medica/HL7_index.html 6. Azpiroz Leehan Joaquín, Martínez Martínez Alfonso, Instalación y Operación de
Sistemas PACS (almacenamiento y comunicación de imágenes) en México, [ On – Line].
http://itzamna.uam.mx/joaquin/pacs/PACS2.html 7. ADOBE, ¿Qué es el formato PDF de ADOBE?,[ On - Line].
http://www.adobe.es/products/acrobat/adobepdf.html 8. Cheguhem Gabriel, Silva Layes Elizabeth, Sistemas de Información y Gestión
Hospitalaria, [On – Line]. www.sis.org.ar/sis2000/sistemas_gestion.pdf 9. Gómez Adrián, González Bernaldo de Quiroz Fernan, Campos Fernando,
Implementación de Mensajeria HL7 para la admisión y egreso de pacientes internos, [ On - Line].
www.sis.org.ar/sis2002/paperssis/SIS27.pdf 10. Gala López Boris L. Salud Proposición de un Diseño y Premisas Teóricas de una
Historia Clínica Computarizada para la Atención Hospitalaria. http://www.cecam.sld.cu/recuimed/revista_tres/articulo_boris.htm
11. Bronzino Joseph D. 1995. The Biomedical Engineering Hand Book. CRC. Florida.
64
12. Leslie Cromwell. 1980. Instrumentación y Medidas Biomédicas. Edición en Español. MARCOMBO. España.
13. Midimate. Audiómetro Zodiac 901 Manual de Usuario. 14. Quinton Inc. 2002. Q-Stress Manual de Usuario. U.S.A 15. Phillips Corp. 2001. Electrocardiógrafo XLi Manual de Referencia. U.S.A 16. Sensor Medics. 1998. Manual de Referencia Vmax Series. U.S.A
65