Desarrollo e implementación de una interfaz HIS/RIS-PACS usando mensajería HL7
24
0
0
Texto completo
(2) HL7 (Health Level Seven) es una organización sin fines de lucro que desarrolla estándares para maximizar las compatibilidades entre sistemas de información en salud, permitiendo la interacción y el intercambio productivo de datos entre aplicaciones heterogéneas, independientemente de su plataforma tecnológica o de su lenguaje de desarrollo.4 Diferentes sectores: prestadores de servicios de salud, desarrolladores de software, consultores, usuarios finales, organizaciones gubernamentales y no gubernamentales; participan en forma colaborativa en la discusión y en el desarrollo de estándares por consenso, en un entorno abierto. Estos estándares ofrecen un marco que permite a los diferentes sistemas de información, comunicarse a través de mensajes que viajan por una única interfaz. En el sector de salud, cada vez se toma más como un estándar, para poder integrarse con aplicaciones ya existentes, simplificando la integración y reutilización de herramientas ya desarrolladas. También reduce la posibilidad de error ya que habitualmente HL7 ya se encuentra en uso. No se consideró ningún RIS que no tuviera HL7 incorporado.. Descripción de escenario inicial El Hospital Alemán cuenta con desarrollos de sistemas propios para el sector administrativo desde hace más de una década. En los últimos años, ha desarrollado un registro de datos clínicos centralizado y digital, con acceso universal desde el propio hospital y los consultorios periféricos y sedes anexas. En el último año se incorporó el estándar de mensajería HL7 en el sector de Terapia Intensiva, para aceptar y enviar mensajes de los monitores de signos vitales. Este proyecto fue desarrollado por completo y está actualmente en la etapa de implementación. A mediados de 2007 se tomó la decisión de incorporar las imágenes médicas generadas en el HA a la Historia Clínica Electrónica en desarrollo en ese momento y brindar acceso digital a las imágenes desde cualquier punto del hospital o incluso fuera de él. Se evaluaron varios sistemas de PACS y RIS, de distintos empresas, open source y hasta eventualmente se barajó la posibilidad de desarrollar uno propio. La reducción de las impresiones de las placas radiográficas fue otro factor determinante para llevar adelante el proyecto. Finalmente se tomo la decisión de instalar PACS y RIS tercerizado de la misma empresa. Al contar con algunas funciones de RIS en el HIS propio desarrollado oportunamente por la gerencia de Sistemas del Hospital, la evaluación sobre que íbamos a usar del RIS, que íbamos a poner el Hospital y como se iban a comunicar los distinto componentes de la implementación (HIS-RIS-PACS) fue un factor clave en la etapa de relevamiento y negociación con la empresa proveedora del RIS-PACS.5.
(3) Para la incorporación del RIS, fue siempre una condición que las interfaces fueran HL7, pues ya contábamos con gateways HL7 y experiencia en el manejo del estándar, y que se modificaran la menor cantidad de aplicaciones existentes, para que fuera transparente para los usuarios que no lo usaban directamente (empleados administrativos de atención al cliente, ingreso de altas, etc.). El Departamento de Imágenes del hospital cuenta con equipos de diversas marcas por lo que era necesario que se pudiera establecer la comunicación con cada uno de ellos de manera eficaz.. Descripción de la solución El primer paso de la implementación fue definir la información que iba a ser compartida entre HIS y RIS y cuáles eran los flujos de trabajo de cada una de ellas, para determinar los sistemas a integrar y en qué lugares podía afectar la implementación. Una vez obtenido esto, se diagramaron cada uno de los flujos de trabajo, especificando donde se usaba la mensajería y cuáles eran los mensajes que iban a ser utilizados. También se definió quienes y que sectores participaban de los procesos. Las interfaces más importantes a definir eran las que afectaban la operatoria diaria, ya que no se debía empeorar la calidad de la atención. Estas son : Ingreso de Ordenes Médicas Informe de los estudios complementarios Definición de Imágenes. Las otras interfaces que se tuvieron que definir fueron : Gestión de Pacientes Gestión de Médicos Procesos de Facturación Ingreso de Ordenes Médicas Esta fue la más complicada de definir. El RIS adquirido incluye la admisión de pacientes y el agendamiento de turnos. En un principio se propuso que el ingreso de los pacientes se hiciera desde el RIS. Esto implicaba que el Hospital tenía que cambiar el sistema de ingreso de ordenes médicas para el servicio de Imágenes. Esto no era aceptado por el área administrativa que exigía el mismo sistema para todo el Hospital, ya que existe un número muy grande de usuarios que rota regularmente..
(4) Lo mismo ocurría con el sistema de turnos, donde se hubiera tenido un sistema para los estudios de imágenes y otro para los demás estudios que realiza el Hospital (al momento de implementar el RIS se estaba terminando de desarrollar un nuevo sistema de turnos que se adaptaba exactamente a las necesidades de todos los servicios del Hospital ). Después de analizar con detalle todos los escenarios posibles, se decidió a que el ingreso se hiciera por el HIS del Hospital. Al finalizar el ingreso se llama al RIS, donde se escanea la orden médica y se arriba al paciente, donde queda ya disponible para ser llamado para la realización del estudio. El RIS informa los estados en los que va estando la orden médica (Iniciada, Finalizada, etc) y la orden escaneada. Los turnos asignados se iban a mantener en ambos sistemas, pero se decidió que no era necesario y que no aportaba mayor información. Igualmente fue desarrollada la interfaz. Los ingresos de las ordenes médicas se pueden realizar, tanto desde el servicio de Imágenes, como desde el servicio de Emergencias y Pediatría.. RIS. HIS. Ingreso orden médica. Estado de la orden. Los estudios que realiza el Hospital debieron ser relevados uno por uno para poder establecer una relación con los definidos para el RIS. Para hacer esto se tuvo que contar con un usuario clave en cada área para definir estas relaciones. Esto no fue un tema trivial ya que la apertura desde el punto de vista administrativo o de la orden médica, al definido en el RIS es muy diferente y conllevo el desarrollo de un modelo de datos ad hoc que será material de otra comunicación. Informe de los estudios El Hospital cuenta con un sistema de informes desarrollado hace varios años. Todos los informes son ingresados desde este sistema y es el que se visualiza desde la historia clínica. Con la incorporación del RIS, todos los informes del departamento de Imágenes empezaron a ingresarse desde la nueva herramienta. Era importante para el Hospital.
(5) conservar todos los informes anteriores y respetar el formato actual de los mismos, por lo que se adaptó el informe del RIS al formato actual de tal manera que no haya diferencias con los que se venían haciendo, ni con los demás informes que se realizan actualmente. Este fue otro factor clave de éxito para el desarrollo del proyecto, ya que para los usuarios el cambio de sistema fue transparente. Una vez generado el informe este es enviado al HIS para poder ser visualizado. Los informes tienen cuatro estados posibles Pre-Informe Validado Invalidado Eliminado El pre-informe es el informe preliminar que es importante para los servicios de emergencia y de internación. Se discutió mucho sobre si debía mostrarse el resultado del informe en la historia clínica o solo informar el estado. Se decidió por ambas. Los preinformes se muestran con una leyenda donde se indica que es un informe preliminar. Al generarse el informe validado se cambia el estado del informe y el contenido, de ser necesario. El ingreso de los informes y su administración es realizada toda desde el RIS.. RIS. Historia Clínica. Informe. Imágenes Para la visualización de las imágenes, hubo que instalar una pieza de software (cliente PACS) en cada equipo donde se deba utilizarse. El cliente permite realizar diferentes operaciones con las imágenes, como aumentarlas o rotarlas. Se tomó la decisión de imprimir a demanda los estudios de los pacientes internados, es decir, la placa no se imprime a menos que sea explícitamente solicitada por algún actor del circuito; por lo que se equipo cada pabellón de internación, los quirófanos y el servicio de emergencias con el equipamiento necesario para poder visualizar los informes y las imágenes. Estas estaciones de visualización están conformadas por.
(6) monitores no diagnósticos, es decir LCD de 19 pulgadas estándar y una PC de alta performance en la cual se ejecuta el cliente PACS. Con el uso del cliente PACS no hubo que desarrollar un aplicativo especial para el manejo de imágenes. Están son administradas exclusivamente por el RIS/PACS, inclusive el almacenamiento. El sistema de historia clínicas se comunica con el cliente PACS, pasándole la información recibida vía mensajería HL7 y este se encarga de mostrar las imágenes pertinentes. Pacientes Los pacientes son administrados exclusivamente por el HIS. Este informa todos los cambios que se producen en el momento. Se hizo una migración con todos los pacientes existentes al comenzar la implementación. Las internaciones de los pacientes al hospital son ingresadas en el HIS y enviadas al RIS. Se mantienen también todos los cambios de habitación que se realiza en el Hospital, los egresos y cualquier otro cambio de la internación. La sincronización del sistema ADT (Admision, Discharge and Transfer) del HIS con el RIS fue otra herraienta de mensajería fundamental para el funcionamiento integrado del RIS-HIS. Se discuten posteriormente los mensajes HL7 elegidos para tal integración. Profesionales de la salud Los profesionales de la salud (médicos, técnicos radiólogos, enfermeras) también son administrados exclusivamente por el HIS. Este informa todas las altas y bajas de médicos que se registran.. Implementación de la mensajería Los mensajes que fueron utilizados para realizar la implementación fueron los siguientes:. -. ADT : Sincronización de Pacientes ORM: Ordenes Médicas DFT : Facturación (Ordenes realizadas e Insumos utilizados) ORU : Resultado de los estudios EPR : Imágenes de estudios MFN : Sincronización de Médicos. Se realizó una división entre los flujo de entrada y de salida al RIS. Los flujos de entrada se denominaron Inbound y los de salida outbound.. ADT.
(7) Introducción Esta sección explica el funcionamiento de la interfaz ADT (Admission/ Discharge/ Transmission) con el fin de aportar al RIS la información en tiempo real de los pacientes del HA. En el próximo párrafo se describen algunos antecedentes generales que se tomaron en cuenta en el proceso de construcción de la interfaz ADT, así como también las restricciones y dependencias. Antecedentes Generales La interfaz ADT fue desarrollada utilizando mensajería HL7 v2.4. La comunicación entre los servidores HL7 es vía TCP/IP – Winsocks. Restricciones Generales Todo ingreso de pacientes debe contener un identificador interno único para el sistema. Los identificadores de ciudades, países, médicos y servicios deben estar sincronizados en las bases de datos RIS y HIS. Debe ser posible fusionar a dos pacientes a partir de la información recibida desde el HIS. No es posible fusionar a más de dos pacientes a la vez. En el sistema RIS no se realizarán admisiones, creaciones ni actualizaciones de pacientes. Estas acciones deben ser ejecutadas por la aplicación respectiva del HA, el sistema RIS tan sólo replicará estos datos.. Dependencias El RIS depende del correcto funcionamiento de todos los sistemas del HA, que estén relacionados con el funcionamiento de interfaces. El RIS depende de los sistemas del HA para la creación de pacientes, médicos, gestión de turnos, gestión de la orden médica y cobro-facturación de las prácticas. Responsabilidades El HIS es el responsable de generar las transacciones de actualización de pacientes. El HIS es el responsable por la integridad de los datos. El RIS no verificará la validez de ningún dato..
(8) Eventos Soportados En la siguiente sección se indican los eventos ADT a utilizar para sincronizar la información demográfica y de admisión de los pacientes. Eventos de gestión de datos demográficos La siguiente tabla muestra los eventos soportados por la integración HIS-RIS: A04 A08 A40 A47. Registro de un nuevo paciente. Modificación de dados demográficos de un paciente. Fusión de 2 pacientes. Cambio del identificador adicional del paciente. Eventos de gestión de admisiones La siguiente tabla muestra los eventos soportados por la integración HIS-RIS: A01 A11 A02 A12 A03. Admisión de pacientes. Cancelación de la admisión. Traslado de paciente. Cancelación del traslado de paciente Alta de un paciente (sano o muerte). Genera el cierre de la admisión del paciente hospitalizado. A13 Cancelación de un alta.. Segmentos Soportados En esta sección se enumeran los segmentos HL7 soportados por el RIS. Segmentos requeridos La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de un mensaje HL7: MSH EVN PID PV1. Segmento correspondiente al encabezado del mensaje. Este segmento entrega información asociada al evento a procesar. Este segmento especifica la información demográfica del paciente. Este segmento contiene información relevante a una admisión de un paciente.
(9) Segmentos opcionales La siguiente tabla muestra los segmentos opcionales para el procesamiento de un mensaje NK1 MRG PD1 AL1. Este segmento contiene información relevante al acompañante del paciente. Este segmento contiene la información del paciente a fusionar. Este segmento contiene información adicional del paciente. Este segmento contiene información sobre alergias que padece el paciente.. Tabla de relación Requerimientos Funcionales – Campo HL7 FR_ADT05 FR_ADT08 FR_ADT09 FR_ADT10 FR_ADT11 FR_ADT12 FT_ADT13 FR_ADT14 FR_ADT15 FR_ADT16 FR_ADT19 FR_ADT23 FR_ADT24 FR_ADT26. MSH-10 PID-3 PID-4 PID-7 PID-8 PID-5 PID-11 PID-13 PID-16 PID-26 NK1-2 y NK1-3 PV1-19 PV1-3 Nuevo lugar en PV1-3 Traslado (Evento A02) FR_ADT27 PV1-3 FR_ADT28 FR_ADT29 FR_ADT30 FR_ADT33 FR_ADT35. ORM Introducción. Nro. de transacción (no el PID-1) Id Paciente Tipo y Nro. de documento. Fecha de Nacimiento (YYYYMMDD) Sexo * (F/M) Apellido ^ Nombre Dirección Teléfono Estado Civil (S/M/W/D) Id País de Residencia Información del acompañante Nro. de admisión = internación Ubicación del paciente. Lugar original Cancelación Traslado (Evento A12) PV1-44 PID-29 y 30 (en Información del alta administrativa caso de muerte) PV1-45 Cancelación Alta Administrativa PID-30 Fecha del alta administrativa. PV1-4 Tipo de admisión PV1-2 Tipo de paciente (E. I).
(10) En esta sección se explica el funcionamiento de la interfaz ORM Inbound con el fin de entregar al HIS la información necesaria para generar los procedimientos requeridos en su base de datos que reflejen como resultado el envió automático de solicitudes desde el HIS al RIS. En esta sección se describen algunos antecedentes generales que se tomaron en cuenta en el proceso de construcción de la interfaz ORM Inbound, así como también las restricciones, dependencias y responsabilidades. Antecedentes Generales La interfaz ORM fue desarrollada utilizando mensajería HL7 v2.4. La comunicación entre los servidores HL7 es vía TCP/IP – Winsocks. El RIS supone que los códigos de facturación serán definidos por HA y serán únicos para cada examen, producto o insumo. Restricciones Generales Todo ingreso de pacientes debe contener un identificador interno para el sistema. El HIS debe asegurar la unicidad de este identificador (Identificador único de paciente). Los médicos y departamentos solicitantes deben poseer un identificador único dentro del HIS que debe ser parametrizado por el personal de imágenes dentro del RIS. El RIS solo aceptará exámenes que estén asociados a un examen válido en el HIS. Dependencias El RIS depende del correcto funcionamiento de todos los sistemas del HA que estén relacionados con el funcionamiento de la interfaz ORM. El RIS depende de la inserción del un número único para la solicitud y examen, estos números generados por el HIS serán el único enlace que permitirá la identificación de la solicitud en posibles modificaciones, cancelaciones, etc. Responsabilidades El RIS depende del oportuno y correcto envío de las solicitudes para informar al servicio de imágenes las prácticas a realizar. El HIS debe asegurar la unicidad de los identificadores de solicitudes y de exámenes asociados a una solicitud.
(11) Eventos Soportados La siguiente tabla muestra el único evento soportado para la integración HIS-RIS: O01 Order Message. Segmentos Soportados Segmentos requeridos La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de un mensaje HL7: MSH PID PV1. Segmento correspondiente al encabezado del mensaje. Este segmento especifica la información demográfica del paciente. Este segmento contiene información relevante a una admisión de un paciente. Segmentos opcionales La siguiente tabla muestra los segmentos opcionales para el procesamiento de un mensaje ORC Este segmento contiene información relevante a la orden OBR Este segmento contiene la información del detalle. OBX Este segmento contiene información de los resultados. Tabla de relación Requerimientos Funcionales – Campo HL7 FR_ORM_IN1 FR_ORM_IN6 FR_ORM_ IN7 FR_ORM_IN8 FR_ORM_IN10 FR_ORM_IN11 FR_ORM_IN16 FR_ORM_IN17 FR_ORM_IN18 FR_ORM_IN19 FR_ORM_IN20 FR_ORM_IN23 FR_ORM_IN24. ORC-25 Turnos (Solicitudes) en estado = “Por aprobar” OBR-13 Información adicional de la solicitud OBR-4.1 Identificador del examen (codigo^descripcion) ORC-2 Identificador de la solicitud/evento ORC-4 y ORC-2 Agrupador de exámenes OBR-3 Orden/Número de llamado ORC-7.6 Prioridad del examen Alta o Normal ORC-25 Estado solicitud paciente hospitalizado = “Aprobado ORC-25 Estado solicitud paciente de guardia = “Aprobado” ORC-25 Estado solicitud al cobrar/autorizar el pago =“Aprobado” ORC-25 Estado solicitud del paciente ambulatorio = “Aprobado” OBR-2 Concatenación del nro. de evento y nro. de examen. OBR-6 Fecha y hora del turno (uso de referencia).
(12) MFN Introducción Esta sección explica el funcionamiento de la interfaz MFN (Master File Notification) con el fin de aportar al RIS la información en tiempo real de los médicos tratantes del HA. En el próximo párrafo se describen algunos antecedentes generales que se tomaron en cuenta en el proceso de construcción de la interfaz MFN, así como también las restricciones y dependencias. Antecedentes Generales La interfaz ADT será desarrollada utilizando mensajería HL7 v2.4. La comunicación entre los servidores HL7 será vía TCP/IP – Winsocks.. Restricciones Generales Todo ingreso de médicos debe contener un identificador único en el sistema. EL RIS no realiza validación alguna sobre la matrícula nacional informada. Dependencias El RIS depende del correcto funcionamiento de todos los sistemas del HA que estén relacionados con el funcionamiento de la interfaz MFN. Dependemos de la unicidad del HIS CODE. Es decir, este código debe ser único. Responsabilidades El HIS es el responsable de generar las transacciones de actualización de médicos. El HIS es el responsable por la integridad de los datos. El RIS no verificará la validez de ningún dato.. Eventos Soportados La siguiente tabla muestra el único evento soportado para la integración HIS-RIS:.
(13) M02 Tabla maestra de médico de staff. Segmentos Soportados Segmentos requeridos La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de un mensaje HL7: MSH MFI. Segmento correspondiente al encabezado del mensaje. Este segmento especifica la tabla maestra de identificación. Segmentos opcionales La siguiente tabla muestra los segmentos opcionales para el procesamiento de un mensaje MFE Este segmento contiene información relevante a la orden STF Este segmento contiene la identificación del staff. PRA Este segmento contiene información del practicante. Tabla de relación Requerimientos Funcionales – Campo HL7 FR_MFN2 FR_MFN3 FR_MFN4 FR_MFN5 FR_MFN6. STF-2 Matricula Nacional * STF-3 Nombre y Apellido del médico solicitante STF-11 Dirección completa STF-10 Teléfono de contacto PRA-5 Especialidad del médico solicitante. Mensajes Outbound ADT Introducción En este documento se explica el funcionamiento de la interfaz ORM Outbound con el fin de informar al HIS el estado de las peticiones e informes médicos. En esta sección se describen algunos antecedentes generales que se tomaron en cuenta en el proceso de construcción de la interfaz ORM Outbound, así como también las restricciones, dependencias y responsabilidades..
(14) Antecedentes Generales La interfaz ORM Outbound será desarrollada utilizando mensajería HL7 v2.4. La comunicación entre los servidores HL7 será vía TCP/IP – Winsocks. El RIS supone que los códigos de facturación serán definidos por HA y serán únicos para cada examen, producto o insumo. Restricciones Generales Todo ingreso de pacientes debe contener un identificador interno para el sistema. El HIS debe asegurar la unicidad de este identificador (Identificador único de paciente). Los médicos y departamentos solicitantes deben poseer un identificador único dentro del HIS que debe ser parametrizado por el personal de imágenes dentro del RIS. El RIS solo aceptará exámenes que estén asociados a un examen válido en el HIS. Dependencias El RIS depende del correcto funcionamiento de todos los sistemas del HA que estén relacionados con el funcionamiento de la interfaz ORM Outbound. El RIS depende de la inserción del un número único para la solicitud y examen, estos números generados por el HIS serán el único enlace que permitirá la identificación de la solicitud en posibles modificaciones, cancelaciones, etc. Responsabilidades El RIS depende del oportuno y correcto envío de las solicitudes para informar al servicio de imágenes las prácticas a realizar. El HIS debe asegurar la unicidad de los identificadores de solicitudes y de exámenes asociados a una solicitud. Eventos Soportados La siguiente tabla muestra el único evento soportado para la integración HIS-RIS: O01 Order Message. Segmentos Soportados.
(15) Segmentos requeridos La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de un mensaje HL7: MSH PID PV1. Segmento correspondiente al encabezado del mensaje. Este segmento especifica la información demográfica del paciente. Este segmento contiene información relevante a una admisión de un paciente. Segmentos opcionales La siguiente tabla muestra los segmentos opcionales para el procesamiento de un mensaje ORC Este segmento contiene información relevante a la orden OBR Este segmento contiene la información del detalle. OBX Este segmento contiene información de los resultados. Tabla de relación Requerimientos Funcionales – Campo HL7. FR_ORM-OUT1 FR_ORM-OUT2 FR_ORM-OUT2 FR_ORM-OUT4 FR_ORM-OUT5 FR_ORM-OUT6 FR_ORM-OUT7 FR_ORM-OUT8 FR_ORM-OUT9 FR_ORM-OUT10 FR_ORM-OUT11 FR_ORM-OUT12. ORU Introducción. ORC-25 Estado = “AR” - “Arribado” ORC-25 Estado = “Escaneado” OBX-5 Ruta a la orden digitalizada ORC-25 Estado = “No encontrado ORC-25 Estado = “A la espera del efecto” ORC-25 Estado = “Iniciado ORC-25 Estado = “Pausado” ORC-25 Estado = “Finalizado” ORC-25 Estado = “Cancelar” ORC-2 Identificador original de la petición/evento OBR-34.5 Número de vestidor/cambiador (el nro de llamado lo deberan tomar del id de la solicitud). OBR-18 Accession Number del RIS. OBR-4 Id del examen o instancia del HA..
(16) Esta sección explica el funcionamiento de la interfaz ORU (Report Outbound) con el fin de aportar al HIS la información en tiempo real de los informes de Diagnóstico por Imágenes. En el próximo párrafo se describen algunos antecedentes generales que se tomaron en cuenta en el proceso de construcción de la interfaz ORU, así como también las restricciones y dependencias Antecedentes Generales La interfaz ORM Outbound será desarrollada utilizando mensajería HL7 v2.4. La comunicación entre los servidores HL7 será vía TCP/IP – Winsocks. Restricciones Generales Los identificadores de ciudades, países, médicos y servicios deben estar sincronizadosen las bases de datos RIS y HIS. Esta interfaz será utilizada para enviar informes desde el RIS al HIS.. Dependencias El RIS depende del correcto funcionamiento de todos los sistemas del HA, que estén relacionados con el funcionamiento de interfazs. El RIS depende de los sistemas del HA para la creación de pacientes, médicos, gestión de turnos, gestión de la orden médica y cobro-facturación de las prácticas. Responsabilidades El RIS es el responsable de generar las transacciones de actualización de pacientes El HIS es el responsable por la integridad de los datos. El RIS no verificará la validez de ningún dato.. Eventos Soportados La siguiente tabla muestra el único evento soportado para la integración HIS-RIS: R01 Resultado de Informe Radiológico..
(17) Segmentos Soportados Segmentos requeridos La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de un mensaje HL7: MSH PID OBR. Segmento correspondiente al encabezado del mensaje. Este segmento especifica la información demográfica del paciente. Este segmento contiene observaciones relevantes. Segmentos opcionales La siguiente tabla muestra los segmentos opcionales para el procesamiento de un mensaje PV1. Este segmento contiene información relevante a una admisión de un paciente ORC Este segmento contiene información relevante a la orden NTE Este segmento contiene notas y cometentarios adicionales OBX Este segmento contiene información de los resultados. Tabla de relación Requerimientos Funcionales – Campo HL7 FR_ORU1 FR_ORU2 FR_ORU2. ORC-2 Identificador HIS de la solicitud PID-2 = PID-3 Identificador del Paciente (PID) OBR-18 Accessión Number. FR_ORU4 FR_ORU5 FR_ORU6 FR_ORU7 FR_ORU8 FR_ORU9. OBR-33 ID Medico Informante OBR-25 Status del informe= “Preinforme” OBR-25 Status del informe=”validado” OBR-25=”F” Status del informe = “validado” sin texto del informe OBR-25=”D” Status del informe = “eliminado” sin texto del informe OBX-5 Texto del informe. EPR Introducción Esta sección explica el funcionamiento de la interfaz EPR con el fin de aportar al HIS la información necesaria que permita cerrar el ciclo de realización de un examen..
(18) En el próximo párrafo se describen algunos antecedentes generales que se tomaron en cuenta en el proceso de construcción de la interfaz EPR, así como también las restricciones y dependencias. Antecedentes Generales La interfaz EPR será desarrollada utilizando mensajería HL7 v2.4. La comunicación entre los servidores HL7 será vía TCP/IP – Winsocks. El RIS supone que los códigos de facturación serán definidos por HA y serán únicos para cada examen, producto o insumo.. Eventos Soportados La siguiente tabla muestra el único evento soportado para la integración HIS-RIS: O01 Order Message. Segmentos Soportados Segmentos requeridos La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de un mensaje HL7: MSH PID PV1. Segmento correspondiente al encabezado del mensaje. Este segmento especifica la información demográfica del paciente. Este segmento contiene información relevante a una admisión de un paciente. Segmentos opcionales La siguiente tabla muestra los segmentos opcionales para el procesamiento de un mensaje ORC Este segmento contiene información relevante a la orden OBR Este segmento contiene la información del detalle. OBX Este segmento contiene información de los resultados. Tabla de relación Requerimientos Funcionales – Campo HL7.
(19) FR_EPR1 FR_EPR2 FR_EPR3 FR_EPR4 FR_EPR5. Imagen en el cache Online OBR-18 Accessión Number PID-2 = PID-3 Patient ID PID-5 Nombre del paciente Imagen fuera del Cache Online. Descripción de la solución técnica El Hospital ya contaba con un servidor de mensajería HL7 corriendo en un servidor Windows 2003. Un servidor de mensajería, como su nombre lo indica, es un servidor que recibe mensajes, los procesa y devuelve una respuesta. A este proceso se le puede aplicar reglas, modificando su contenido o devolviendo un resultado. Dichas reglas puede generar acciones de de distintos tipo tal como enviar mails de alerta para avisar si ocurrió algún tipo de error. La comunicación para el envío de la información desde el HIS es por un puerto TCP/IP y para recibir los mensajes se graba directamente sobre una tabla en la base de datos Oracle (Previamente hubo que instalar el Oracle Data Provider para .NET (ODP.NET). Este usa rutinas Oracle para brindar un acceso rápido y confiable a datos Oracle desde cualquier aplicación .NET). La solución desde el lado de la base de datos fue desarrollada completamente en PL/SQL, con paquetes y funciones que se almacenan en la base de datos. El PL/SQL es el lenguaje de programación de SQL de Oracle y las rutinas utilizadas son las que vienen en la instalación del producto. La versión de Oracle fue la 10.2.0.1.0. Las funciones utilizadas para comunicarse con el servidor, son muy parecidas en otros lenguajes de programación (C, C#, Java). Las rutinas de manejo del XML6 están incorporadas en la versión actual de la base de datos. Oracle implementa funciones estándar que permite hacer consultas relacionales y devolver documentos XML. Todas estas funciones forman parte del estándar ANSI/ISO SQL. Este ha tenido gran aceptación entre las empresas de desarrollo de base de datos ( IBM, Microsoft, Oracle). En la Figura 1 se ve puede ver un diagrama de la solución implementada. Los “Mensajes Outbound son para el envío de información desde el RIS al HIS. Los “Mensajes Inbound” y “Grabación Oracle”, son para recibir la información. El envío y recepción de información son sucesos independientes. El “Mensaje Inbound XML” esta especificado así, por que se genera en XML pero el servidor de Mensajería lo pasa en texto para que pueda ser interpretado correctamente por el RIS. Esta es una funcionalidad que provee el servidor de mensajería..
(20) Mensajería Inbound. Mensajes Outbound. Mensajes Inbound XML Base de datos Oracle Grabación Oracle Servidor de Mensajería. -Figura.1-. Descripción del desarrollo Mensajes Inbound XML A continuación se describe la rutina que se utiliza para el envío de la mensajería. Primero se graba en una tabla, luego se abre la conexión TCP , se envía la información, se cierre y se actualiza la tabla. Este procedimiento me permite verificar el estado del mensaje enviado. PROCEDURE SEND_MSG(p_msgXml xmltype) BEGIN INSERT INTO VALUES RETURNING INTO. HA.HL7_SENT_MESSAGES(MSG,CDATE,ESTADO) (p_msgXml,SYSTIMESTAMP,NULL) ROWID v_rowid;. msg_text_encoded := CHR(11)||p_msgXml.getStringVal()||CHR(28)||CHR(13); BEGIN c. := UTL_TCP.OPEN_CONNECTION(remote_host =>HL7_HOST, remote_port =>HL7_PORT, tx_timeout => HL7_TIMEOUT ); rc := UTL_TCP.write_text(c, msg_text_encoded);. v_tcp_ok := TRUE; EXCEPTION WHEN OTHERS THEN v_tcp_ok := FALSE; END; IF. v_tcp_ok THEN utl_tcp.flush(c);.
(21) msg_response :=NULL; BEGIN LOOP v_response := utl_tcp.get_text(c,1); v_estado := 'P'; EXIT WHEN ASCII(v_response)=13 AND v_ascii_ant=28; msg_response := msg_response ||v_response ; v_ascii_ant := ASCII(v_response); END LOOP; msg_response := SUBSTR(msg_response,2,Length(msg_response)-2); v_msg_answer := xmltype(msg_response); EXCEPTION WHEN OTHERS THEN v_estado := 'E'; IF sqlcode = -29276 THEN v_msg_answer := xmltype('TIMEOUT:'||sqlcode); ELSE v_msg_answer := xmltype('ERROR:'||sqlerrm); END IF; END ; UPDATE HA.HL7_SENT_MESSAGES SET ESTADO = v_estado, ANSWER = v_msg_answer WHERE ROWID = v_rowid; COMMIT; END IF; -- Cierro TCP con o sin error. BEGIN UTL_TCP.CLOSE_CONNECTION(c); EXCEPTION WHEN OTHERS THEN NULL; END;. Mensajes Outbound El servidor de mensajes graba en la tabla HL7_MESSAGES(MSG XMLTYPE). Una veza grabado se ejecuta el trigger que lo pasa a la tabla COLA_MSG_XML y luego se ejecuta la rutina encargada de procesar el mensaje. Este proceso el que administra la cola de los mensajes y reintenta procesar el mensaje 3 veces, con un intervalo de tiempo determinado. BEGIN v_xml := Xmltype(:NEW.Msg); INSERT INTO HA.COLA_MSG_XML(MSG_ID,MSG,CDATE,ESTADO) VALUES(v_Msg_Id,v_xml,SYSTIMESTAMP,'E'); END;. HA.Procesar_Cola_Xml;. Para procesar el mensaje se llama a una rutina que analiza cual es el origen del mensaje para saber cual es el proceso a seguir..
(22) Programación de las rutinas Se utilizo el PL/SQL de Oracle y se manejaron los mensajes como XML. Esto facilito mucho el desarrollo de las interfaces, ya que Oracle cumple los estándares para manejo de documentos XML (Xpath) que permite inclusive usarlo en sentencias SQL. Ejemplo de la generación de un ADT. SELECT xmlelement("ADT_A01",XMLATTRIBUTES(PK_HL7.xmlns_urn AS "xmlns"), xmlagg( xmlConcat(PK_HL7.MSH('ADT',p_evento,'ADT^A01'), PK_HL7.EVN(SYSDATE), PK_HL7.PID(p_paciente), PK_HL7.PV1(NULL,NULL,NULL,NULL) ) ) ) INTO v_msgXml FROM Dual; FUNCTION MSH(p_msgType VARCHAR2,p_trigger VARCHAR2, p_msgStructure VARCHAR2:=NULL) RETURN xmltype IS mshXml xmltype; msgControlId NUMBER; v_msgStructure VARCHAR2(10):=NVL(p_msgStructure,p_msgtype||'^'||p_trigger); BEGIN SELECT HA.SEQ_HL7.Nextval INTO msgControlid FROM DUAL; --- MSH mshXml:=xmltype('<MSH>'|| '<MSH.1>|</MSH.1> '|| '<MSH.2>^~\&</MSH.2>'|| '<MSH.3><HD.1>HIS_HA</HD.1></MSH.3>'|| '<MSH.7><TS.1>'||TO_CHAR(SYSDATE,c_dateFormat)||'</TS.1></MSH.7>' || '<MSH.9><CM_MSG.1>'||p_msgType ||'</CM_MSG.1>'|| '<CM_MSG.2>'||p_trigger ||'</CM_MSG.2>'|| '<CM_MSG.3>'||v_msgStructure||'</CM_MSG.3>'|| '</MSH.9>'|| '<MSH.10>'||TO_CHAR(msgControlId) ||'</MSH.10>'|| '<MSH.11> <PT.1>'||PK_HL7.p_processingId ||'</PT.1></MSH.11>'|| '<MSH.12><VID.1>2.4</VID.1></MSH.12>'|| '<MSH.17>ARG</MSH.17>'|| '</MSH>'); RETURN mshXml; END MSH; FUNCTION PID(p_paciente NUMBER) RETURN xmltype IS pacienteXml xmltype; BEGIN SELECT xmlelement("PID", xmlagg( xmlelement("PID.3", xmlelement("CX.1",p.paciente), xmlelement("CX.4", xmlelement("HD.1",'HA') ), xmlelement("CX.5",'MR') ) ), DECODE(MIN(p.nrodoc),NULL,NULL, xmlagg( xmlelement("PID.4", xmlelement("CX.1",HA.CONVIERTE_CHAR_ESP(p.nrodoc)), xmlelement("CX.4", xmlelement("HD.1",'ARG') ), xmlelement("CX.5",DECODE(p.tipdoc,'PPT','PAS',p.tipdoc)).
(23) ) ) ), xmlagg( xmlelement("PID.5", xmlelement("XPN.1", xmlelement("FN.1",p.priape||' '||p.otrosape) xmlelement("XPN.2",p.prinom||' '||p.otrosnom) ) ), xmlagg( xmlelement("PID.7", xmlelement("TS.1",TO_CHAR(p.fecnac,c_dateFormat_short)) ) ), xmlagg( xmlelement("PID.8",p.sexo ) ), xmlagg( xmlelement("PID.11", xmlelement("XAD.1", xmlelement("SAD.1",HA.CONVIERTE_CHAR_ESP(p.domic)) ), xmlelement("XAD.3",HA.CONVIERTE_CHAR_ESP(p.local)), xmlelement("XAD.4",HA.CONVIERTE_CHAR_ESP(p.prov)), xmlelement("XAD.5",HA.CONVIERTE_CHAR_ESP(p.codpost)), xmlelement("XAD.6",'ARG') -- Country ) ), xmlagg( xmlelement("PID.13", xmlelement("XTN.4",HA.CONVIERTE_CHAR_ESP(p.email)), xmlelement("XTN.7", DECODE(p.contactel,'F',p.telef,'O',p.telefc,telefcel)) ) ), xmlagg( xmlelement("PID.16", xmlelement("CE.1", DECODE(p.estcivil,'1','S','2','M','3','W','4','D')) ) ), xmlagg( xmlelement("PID.30",DECODE(p.fallecio,'1','Y','N')) ) ) INTO pacienteXml FROM hospital.paciente p WHERE p.paciente = p_paciente; RETURN pacienteXml; END PID;. Discusión El uso de interfaces HL7 en la adaptación de un sistema RIS/PACS es clave para el éxito del proyecto. Contar con un estándar ya definido simplifica el trabajo y disminuye la posibilidad de error, tanto desde el HIS como desde el RIS. Otro factor importante fue logar que el HIS siga siendo el generador de ordenes médicas. Esto fue fundamental, no solo para poder contar con el apoyo de todas las áreas intervinientes, ya que se modificó lo menos posible el trabajo de las mismas, sino también para disminuir los posibles errores..
(24) Igualmente es importante destacar que los flujos de trabajos sufrieron muchos cambios cuando estos se aplicaron a la real dinámica de los sectores. Muchas situaciones ideales fueron cambiadas debido a errores en la confección de las órdenes médicas, ya sea por la elección del estudio incorrecto, como el agregado de nuevos estudios a las órdenes. El modelo de datos de estudios del RIS demando más trabajo del provisto originalmente, en parte por la gran apertura que se tenía en el HIS y otra por la manera de trabajar de algunos equipos DICOM compatibles, que tomaban una sola muestra de varios estudios, lo que traía problemas al informar. No obstante toda la problemática antes mencionada, la incorporación del RIS significo una mejora sustancial en la calidad de los informes y en la atención de los pacientes. Finalmente, el desarrollo de las interfaces fue menos complicado de lo previsto, usando estándares de uso cotidiano, y la experiencia del uso mensajería HL7 deja al Hospital preparado para nuevas interfaces a desarrollar. Referencias. 1. NEMA. PROCEDURES for the DICOM Standards Committee. 2007. Available at: http://medical.nema.org/Dicom/Geninfo/Procedures.pdf.. 2. PACS. Available at: http://renux.dmed.ed.ac.uk/EdREN/PACSpres/PACS.html [Accessed June 14, 2009].. 3. Manzotti M, Diaz M, Segarra G. Informatización de la actividad médica asistencial en un hospital de la comunidad en Argentina. In: ; 2007. Available at: http://www.sais.org.ar/Portals/2/SIS/SIS2007/Trabajos/09_Manzotti.pdf.. 4. Catálogo de Recursos de HL7 - HL7 - Argentina. Available at: http://hl7.org.ar/index.php?option=com_content&task=view&id=53&Itemid=89 [Accessed June 14, 2009].. 5. Espinoza M, Maldonado S, Segarra G. Integración RIS/PACS Comunicación HL7 vs. DICOM. Visualización de imágenes en un sistema PACS dentro de una aplicación de Historia Clínica de Pacientes (EPR). In: Asociación Médica Argentina.. 6. Extensible Markup Language (XML). Available at: http://www.w3.org/XML/ [Accessed June 14, 2009]..
(25)
Documento similar
