• No se han encontrado resultados

RIS RADIOLOGIA

N/A
N/A
Walter Fernando Rodrìguez Merlo

Academic year: 2022

Share "RIS RADIOLOGIA"

Copied!
35
0
0

Texto completo

(1)

¿Qué es HL7?

Logotipo de Health Level Seven International

HL7 son las siglas de la organizaciónHealth Level Seven International. Se trata de una organización sin ánimo de lucro que se dedica a la creación de estándares de informática de la salud.

HL7 fue fundada en 1987 y participan en ella más de 1.600 miembros de 50 países. Entre los miembros, hay más de 500 organizaciones de todos los ámbitos de la salud. Existen diferentes ramas nacionales de HL7, por ejemplo, la rama española esHL7 Spain.

¿Existió HL6 o HL5?

La respuesta es NO. Health Level Seven hace referencia al nivel 7 delmodelo OSI, el nivel de aplicación, para el sector salud. Según la Wikipedia, el nivel 7 «ofrece a las aplicaciones la posibilidad de acceder a los servicios de las demás capas y define los protocolos que utilizan las aplicaciones para intercambiar datos. Por tanto, Health Level Seven quiere decir «Nivel de Aplicación en Salud» y se refiere a los protocolos y estándares para intercambiar información entre aplicaciones de salud.

En resumen, HL7 se encarga de definir un marco de trabajo y estándares para el intercambio, la integración y el acceso a la información electrónica de salud.

¿Qué son los estándares HL7?

Los estándares HL7 o protocolos HL7 indican cómo se organiza y comunica la información entre dos partes. Estos estándares definen el idioma, la estructura y los tipos de datos requeridos para una integración fluida entre sistemas de salud.

Miles de hospitales en todo el mundo utilizan a diario estos estándares para intercambiar información entre sus sistemas. Si hablamos de estándares HL7, hablamos de interoperabilidad en salud.

Además de los estándares HL7, existen muchos otros que aparecen a menudo junto a ellos. Puedes consultar nuestraguía de estándares de interoperabilidad en saludpara saber más.

¿Cuáles son los estándares HL7 más importantes?

Los estándares HL7 más importantes son HL7 V2, HL7 V3, CDA, HL7 FHIR y CCOW. Estos cinco son los que se conocen como estándares primarios (HL7 primary standards) y son los más usados para la integración de sistemas y la interoperabilidad.

(2)

Estándares HL7 primarios: HL7 V2, HL7 V3, CDA, FHIR, CCOW

Hay una gran cantidad deinformación sobre los estándares primariosen la web de HL7.

El estándar HL7 V2

Elestándar HL7 V2(o protocolo HL7 V2) es unestándar de mensajeríaque permite el intercambio de información entre distintos sistemas. Es, sin duda, el más extendido y usado de losestándares de interoperabilidad.

Su primera versión se publicó en octubre de 1987, desde entonces se han publicado múltiples actualizaciones. Las versiones se nombran habitualmente de la forma V2.X. En 2014 se publicó la versión HL7 V2.8 que es la más reciente a la fecha de este artículo.

La versión más utilizada de HL7 versión 2 es la V2.5, aunque es muy frecuente encontrar también las versiones V2.3, V2.6 y V2.7.

La mensajería HL7 V2

Existen muchos tipos de mensajes HL7 V2, pero los más usados son los de gestión de paciente (ADT), órdenes (ORM) y resultados (ORU). Los mensajes son cadenas de texto divididas en segmentos. El segmento más importante es la cabecera o segmentoMSH, que aparece en primer lugar y contiene, entre otros datos, el tipo de mensaje que es.

(3)

Los mensajes de HL7 V2 tienen un aspecto muy característico, son varias líneas de texto largas similares a las siguientes:

En estos mensajes, cada línea corresponde a un segmento que se identifica por sus tres primeras letras. A continuación de la identificación del segmento, vienen los campos de ese segmento. Estos campos, a su vez, están formados por componentes y subcomponentes.

Los campos, componentes y subcomponentes se separan mediante caracteres separadores especiales. Los caracteres recomendados son:

“|”: separador de campos (barra o pipe).

“^”: separador de componentes (gorro o hat).

“&”: separador de subcomponentes.

“~”: separador en iteraciones de campos.

“\”: carácter de escape.

Desde la versión 2.3 del estándar HL7 se pueden codificar los mensajes también en formato XML.

Esta codificación se denominav2.xml.

Recursos sobre HL7 V2 en Health Level Seven International (en inglés):

Resumen de HL7 V2.

Codificación en XML de mensajería HL7 V2 – v2.xml

Guías de implementación de HL7 V2.

HL7 V2 vs HL7 V3

El estándar HL7 V2 es el más usado, pero tiene algunos inconvenientes. HL7 V2 tienen una gran flexibilidad y es adaptable a casi todos los casos, pero esta flexibilidad tiene un coste. Este coste es que las diferencias entre distintas implementaciones requieren profundos análisis y mucha negociación para conseguir la integración. Por otro lado, esta flexibilidad y diferencias también hacen que sea complicado testear y llevar a cabo pruebas de conformidad.

(4)

Esta situación impulsó el desarrollo del estándar HL7 V3. Este estándar es mucho más ambicioso y amplio que la versión anterior. El enfoque de este nuevo estándar es mucho más formal y pretende solucionar algunos de los inconvenientes de su versión anterior.

El estándar HL7 V3

Elestándar HL7 V3pretende cubrir todos los aspectos de la implementación: mensajería, tipos de datos y terminologías. Estas características lo convierten en una iniciativa muy ambiciosa dentro de losestándares de interoperabilidad. Esta versión del estándar tiene una aproximación semántica, basada en modelos, que es mucho más estricta y normativa que en la versión 2. La primera versión de HL7 versión 3 fue lanzada en 2003 y ha seguido actualizándose desde entonces.

La mensajería y documentos de la versión 3 se definen en sintaxis XML, a diferencia del formato de pipes usado en HL7 V2. Asimismo, insiste mucho en el uso devocabularios controlados(comoCIE-10,LOINCySNOMED CT), además de codificaciones propias.

La complejidad y extensión de HL7 versión 3 hacen que no sea fácil de implantar ni de migrar desde la versión 2. Además, tiene que competir con la misma versión 2, que se encuentra en producción de forma satisfactoria en casi todas partes. Quizá por estos motivos, la versión 3 del estándar no está tan extendida como la versión anterior, no obstante, es usada en varios servicios públicos de salud como Reino Unido, Países Bajos y Canadá.

Recursos sobre HL7 V3 en la web de Health Level Seven International (en inglés):

Resumen de HL7 V3.

Guías de implementación de HL7 V3.

HL7 V3 RIM: Reference Information Model

Una de las principales características del estándar HL7 V3 es que está basado en elRIM (Reference Information Model), un amplio modelo de objetos de referencia de los datos clínicos.

El RIM es un modelo de toda la información de los servicios sanitarios, que identifica el ciclo de vida de la mensajería dentro de la actividad clínica. Este modelo es la referencia que se usa para el desarrollo de todo el estándar.

(5)

Diagrama UML de HL7 RIM

Información sobre RIM en Health Level Seven International (en inglés):

Resumen de HL7 V3 RIM.

Estándar HL7 RIM.

El estándar HL7 CDA®

El estándar HL7 CDA®es unestándar de documento clínico. Esta especificación tiene el objetivo de facilitar el intercambio de información en forma de documentos entre proveedores de salud y pacientes. CDA puede contener cualquier tipo de información clínica, por ejemplo: informes de alta, informes de radiología, informes de patología o la exploración y anamnesis del paciente.

CDA es la abreviatura de Clinical Document Architecture (Arquitectura de Documento Clínico). La primera versión (CDA Release 1) fue lanzada en el año 2000, la segunda versión (CDA Release 2 o CDAR2) fue lanzada en 2005 y adoptada como estándar ISO/HL7 27932:2009.

CDA está basado en el modelo de datos RIM y en la metodología de trabajo de HL7 V3.

Características de un documento CDA

Según el estándar CDA, las seis características que debe tener un documento clínico son:

(6)

Persistencia: el documento permanece inalterado en el tiempo, independientemente de cambios externos.

Custodia: el documento debe ser administrado por una organización o entidad.

Potencial para la autenticación: el documento ha de tener validez legal.

Contexto: el documento define un contexto de participantes (como el paciente o el médico), acto, prestador de servicios sanitarios, etc.

Completitud: el documento se debe entender como una unidad de contenido.

Legibilidad humana: aunque puede ser procesado por sistemas informáticos, el documento debe conservar la capacidad de ser leído por personas.

Estructura de un documento CDA

El objetivo del estándar HL7 CDA es definir la parte estructural y semántica del documento, pero no se ocupa del contenido de los documentos. Cómo se crean, almacenan e intercambian los documentos queda fuera del alcance del estándar.

Un documento CDA se especifica en formato XML y se compone de dos partes: la cabecera (header) y el cuerpo (body).

La cabecera o header contiene metainformación sobre el documento:

Atributos del encabezado: identificación, fecha, título, idioma, etc.

Participantes: el autor, el paciente, el proveedor, etc.

Actos relacionados: otros documentos, autorizaciones, etc.

El cuerpo o body contiene la información del documento. Dicha información siempre debe contener una parte textual que asegure la legibilidad humana. El estándar define tres niveles de estructura para el cuerpo:

Nivel 1: contenido no estructurado. Por ejemplo, el contenido puede ser un documento PDF incrustado.

Nivel 2: contenido estructurado y codificado en secciones.

Nivel 3: contenido completamente estructurado y codificado.

La codificación del contenido de los documentos se realiza medianteestándares de codificación, comoSNOMED-CT,CIE-10 (ICD-10)yLOINC.Cuanto mayor sea el nivel de codificación del contenido del documento, mayor será su grado de interoperabilidad con otros sistemas.

Recursos sobre CDA Release 2 en la web Health Level Seven International:

Resumen de CDAR2.

Guías de implementación de CDA.

(7)

CDA en Wikipedia.

El estándar HL7 FHIR®

HL7 FHIR®es unestándar de interoperabilidadque combina lo mejor de HL7 V2, HL7 V3 y CDA y se enfoca en facilitar su implementación. Además, usa los estándares web más frecuentes, como XML, JSON y HTTP.

FHIR®es la abreviatura de Fast Healthcare Interoperability Resources (Recursos de Interoperabilidad Sanitaria Rápida). Los Resources o recursos son las piezas clave de FHIR.

¿Qué son los Resources FHIR?

Los «Resources» son los bloques de construcción de todos los intercambios de información en FHIR. Cada Resource o recurso representa un concepto de la realidad de la atención sanitaria, como pacientes, citas, organizaciones o resultados de pruebas.

Los recursos pueden representarse tanto en XML como en JSON y todos tienen ciertas características en común:

Una URL que identifica al Resource.

Unos metadatos comunes.

Un resumen legible para humanos.

Un marco de extensibilidad (extensibility framework) que permite asumir las diferencias en la atención sanitaria.

Vemos una representación de un Resource de paciente donde se han resaltado las partes características:

(8)

Ejemplo de Resource de paciente. Fuente:https://www.hl7.org/fhir/summary.html

Usando estos recursos o Resources se pueden modelar los procedimientos clínicos y administrativos de forma rápida y con menos complejidad que con otras alternativas.

Es posible consultarla lista completa de Resources de FHIR, donde hay más de 115 recursos definidos. Además, en cada recurso se incluye documentación y ejemplos.

¿Cómo se manejan e intercambian los Resources en FHIR?

Desde su concepción, FHIR está diseñado para la interoperabilidad y define unaAPI RESTpara el intercambio, manipulación y búsqueda de recursos. Mediante esta API es posible crear, modificar, eliminar y buscar los recursos.

(9)

Por ejemplo, para crear un paciente, tendríamos que crear el recurso y enviarlo mediante una petición POST al endpoint REST correspondiente:

POST https://path-servidor/Patient

Para solicitar un paciente, usaríamos una petición GET:

GET POST https://path-servidor/Patient/{id}

Existe gran cantidad de documentación en la web de FHIR:

Documentación sobre laAPI REST de FHIR.

Guía para el desarrollador FHIR, que es un buen sitio por dónde empezar.

La organización de FHIR: niveles y módulos

El estándar FHIR estáorganizado en módulosque representan las distintas áreas funcionales de la especificación. Los módulos, a su vez, se agrupan en niveles, donde cada nivel corresponde a un nivel de abstracción superior.

Los niveles son, del más fundamental al más abstracto:

Nivel 1: Marco básico en el que se basa la especificación.

Nivel 2: Soporte a la implementación y relación con especificaciones externas.

Nivel 3: Relación con conceptos del mundo real en el sistema de atención sanitaria.

Nivel 4: Registro e intercambio de datos para el proceso de atención sanitaria.

Nivel 5: Provisión de la habilidad de razonar sobre el proceso de atención sanitaria.

En la siguiente imagen extraída de la web de FHIR se pueden observar los distintos niveles y los módulos que los componen:

(10)

Organización de los módulos en niveles de FHIR.

Fuente: https://www.hl7.org/fhir/modules.html#modules Recursos sobre FHIR en Health Level International:

Resumen de FHIR.

Página de HL7 FHIR.

Introducción a FHIR para desarrolladores.

El estándar CCOW

CCOW (Clinical Context Object Workgroup) es un estándar de interoperabilidad que pretende facilitar la integración de aplicaciones a nivel de uso mediante una técnica denominada Context Management.

Esta técnica permite sincronizar y unificar a nivel de interfaz de usuario la información de distintos sistemas que contienen información referida al mismo paciente, procedimiento o usuario.

Recursos en la web de Health Level Seven International:

(11)

Resumen de CCOW.

Conclusión

Aunque no son los únicos, en este artículo hemos visto los principales estándares HL7. Entre todos, destaca la mensajería HL7 V2 que podemos encontrar en casi cualquier sistema de información de salud. Además, conviene seguir de cerca al estándar FHIR, que promete ser el gran heredero en el futuro de la interoperabilidad en salud.

(12)

Desarrollo e implementación de una interfaz HIS/RIS-PACS usando mensajería HL7

Segarra G.

1,

Diaz M.

2

1Área de Desarrollo de Sistemas Hospital Alemán de Buenos Aires,2 Área de Informática Médica del Hospital Alemán de Buenos Aires

Resumen

En el servicio de Imágenes del Hospital Alemán se decidió mejorar la calidad y reducir la impresión de placas incorporando un sistema RIS/PACS. Una de las premisas fue que tuviera una interfaz con la historia clínica del Hospital, para compartir las imágenes y los resultados ,como así también los procesos administrativos.

Este artículo describe las características principales de esa implementación usando las interfaces provistas por el RIS adquirido para cumplir con el mencionado fin y una breve descripción de cómo se desarrollo la mensajería..

Palabras Clave

HL7, RIS, HIS, PACS,XML

Introducción

Un Sistema de Información Radiológica RIS (Radiology Information System), es la herramienta informática que nos permite realizar los procesos de gestión de un departamento de radiología; gestiona la información y sostiene la comunicación del departamento con otros servicios de información del hospital.

DICOM (Digital Imaging and Communication in Medicine) es el estándar reconocido mundialmente para el intercambio de imágenes médicas, pensado para el manejo, almacenamiento, impresión y transmisión de las mismas. Incluye la definición de un formato de archivo y de un protocolo de comunicación de red. Los ficheros DICOM pueden intercambiarse entre dos entidades que tengan capacidad de recibir imágenes y datos de pacientes en formato DICOM.1

El PACS (Picture Archiving and Communication System) automatiza el proceso de obtención de imágenes digitales desde equipos de imagenología existentes (Tomógrafos, Ecógrafos, Resonadores), generalmente utilizando el estándar DICOM.

Trabaja en forma integrada con el RIS, ya que este es el encargado de enviarle las ordenes médicas, la información con respecto a los pacientes, los médicos y también de administrar las agendas de turnos de las diferentes modalidades y salas del departamento de imágenes.2

Parte conformante del HIS (Hospital Information System), es el sistema que administra los servicios del Hospital, las agendas, la generación de las ordenes médicas como así también la facturación de los mismos. Tambien forma parte del HIS el servidor de resultados que permite cargar los informes de los estudios complementarios realizados en el hospital y comunica a los diferentes usuarios los mismos.3

(13)

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

(14)

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.

(15)

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.

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 fu e 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

Ingreso orden médica HIS RIS

Estado de la orden

(16)

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 pre- informes 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.

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

Informe

RIS Historia Clínica

(17)

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

(18)

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.

(19)

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 Registro de un nuevo paciente.

A08 Modificación de dados demográficos de un paciente.

A40 Fusión de 2 pacientes.

A47 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 Admisión de pacientes.

A11 Cancelación de la admisión.

A02 Traslado de paciente.

A12 Cancelación del traslado de paciente

A03 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 Segmento correspondiente al encabezado del mensaje.

EVN Este segmento entrega información asociada al evento a procesar.

PID Este segmento especifica la información demográfica del paciente.

PV1 Este segmento contiene información relevante a una admisión de un paciente

(20)

Segmentos opcionales

La siguiente tabla muestra los segmentos opcionales para el procesamiento de un mensaje

NK1 Este segmento contiene información relevante al acompañante del paciente.

MRG Este segmento contiene la información del paciente a fusionar.

PD1 Este segmento contiene información adicional del paciente.

AL1 Este segmento contiene información sobre alergias que padece el paciente.

Tabla de relación Requerimientos Funcionales – Campo HL7

FR_ADT05 MSH-10 Nro. de transacción (no el PID-1)

FR_ADT08 PID-3 Id Paciente

FR_ADT09 PID-4 Tipo y Nro. de documento.

FR_ADT10 PID-7 Fecha de Nacimiento (YYYYMMDD)

FR_ADT11 PID-8 Sexo * (F/M)

FR_ADT12 PID-5 Apellido ^ Nombre

FT_ADT13 PID-11 Dirección

FR_ADT14 PID-13 Teléfono

FR_ADT15 PID-16 Estado Civil (S/M/W/D)

FR_ADT16 PID-26 Id País de Residencia

FR_ADT19 NK1-2 y NK1-3 Información del acompañante FR_ADT23 PV1-19 Nro. de admisión = internación

FR_ADT24 PV1-3 Ubicación del paciente

FR_ADT26 Nuevo lugar en PV1-3 Traslado (Evento A02)

FR_ADT27 PV1-3 Lugar original Cancelación Traslado (Evento A12)

FR_ADT28 PV1-44 PID-29 y 30 (en caso de muerte)

Información del alta administrativa

FR_ADT29 PV1-45 Cancelación Alta Administrativa FR_ADT30 PID-30 Fecha del alta administrativa.

FR_ADT33 PV1-4 Tipo de admisión

FR_ADT35 PV1-2 Tipo de paciente (E. I)

ORM

Introducción

(21)

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

(22)

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 Segmento correspondiente al encabezado del mensaje.

PID Este segmento especifica la información demográfica del paciente.

PV1 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 ORC-25 Turnos (Solicitudes) en estado = “Por aprobar”

FR_ORM_IN6 OBR-13 Información adicional de la solicitud

FR_ORM_ IN7 OBR-4.1 Identificador del examen (codigo^descripcion) FR_ORM_IN8 ORC-2 Identificador de la solicitud/evento

FR_ORM_IN10 ORC-4 y ORC-2 Agrupador de exámenes FR_ORM_IN11 OBR-3 Orden/Número de llamado

FR_ORM_IN16 ORC-7.6 Prioridad del examen Alta o Normal

FR_ORM_IN17 ORC-25 Estado solicitud paciente hospitalizado = “Aprobado FR_ORM_IN18 ORC-25 Estado solicitud paciente de guardia = “Aprobado”

FR_ORM_IN19 ORC-25 Estado solicitud al cobrar/autorizar el pago =“Aprobado”

FR_ORM_IN20 ORC-25 Estado solicitud del paciente ambulatorio = “Aprobado”

FR_ORM_IN23 OBR-2 Concatenación del nro. de evento y nro. de examen.

FR_ORM_IN24 OBR-6 Fecha y hora del turno (uso de referencia)

(23)

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:

(24)

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 Segmento correspondiente al encabezado del mensaje.

MFI 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 STF-2 Matricula Nacional *

FR_MFN3 STF-3 Nombre y Apellido del médico solicitante FR_MFN4 STF-11 Dirección completa

FR_MFN5 STF-10 Teléfono de contacto

FR_MFN6 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.

(25)

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

(26)

Segmentos requeridos

La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de un mensaje HL7:

MSH Segmento correspondiente al encabezado del mensaje.

PID Este segmento especifica la información demográfica del paciente.

PV1 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 ORC-25 Estado = “AR” - “Arribado”

FR_ORM-OUT2 ORC-25 Estado = “Escaneado”

FR_ORM-OUT2 OBX-5 Ruta a la orden digitalizada FR_ORM-OUT4 ORC-25 Estado = “No encontrado

FR_ORM-OUT5 ORC-25 Estado = “A la espera del efecto”

FR_ORM-OUT6 ORC-25 Estado = “Iniciado FR_ORM-OUT7 ORC-25 Estado = “Pausado”

FR_ORM-OUT8 ORC-25 Estado = “Finalizado”

FR_ORM-OUT9 ORC-25 Estado = “Cancelar”

FR_ORM-OUT10 ORC-2 Identificador original de la petición/evento

FR_ORM-OUT11 OBR-34.5 Número de vestidor/cambiador (el nro de llamado lo deberan tomar del id de la solicitud).

FR_ORM-OUT12 OBR-18 Accession Number del RIS.

OBR-4 Id del examen o instancia del HA.

ORU

Introducción

(27)

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.

(28)

Segmentos Soportados

Segmentos requeridos

La siguiente tabla muestra los segmentos requeridos para el correcto procesamiento de un mensaje HL7:

MSH Segmento correspondiente al encabezado del mensaje.

PID Este segmento especifica la información demográfica del paciente.

OBR 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 ORC-2 Identificador HIS de la solicitud

FR_ORU2 PID-2 = PID-3 Identificador del Paciente (PID) FR_ORU2 OBR-18 Accessión Number

FR_ORU4 OBR-33 ID Medico Informante

FR_ORU5 OBR-25 Status del informe= “Preinforme”

FR_ORU6 OBR-25 Status del informe=”validado”

FR_ORU7 OBR-25=”F” Status del informe = “validado” sin texto del informe FR_ORU8 OBR-25=”D” Status del informe = “eliminado” sin texto del informe FR_ORU9 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.

(29)

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 Segmento correspondiente al encabezado del mensaje.

PID Este segmento especifica la información demográfica del paciente.

PV1 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

(30)

FR_EPR1 Imagen en el cache Online FR_EPR2 OBR-18 Accessión Number FR_EPR3 PID-2 = PID-3 Patient ID FR_EPR4 PID-5 Nombre del paciente FR_EPR5 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.

(31)

-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 HA.HL7_SENT_MESSAGES(MSG,CDATE,ESTADO) VALUES (p_msgXml,SYSTIMESTAMP,NULL)

RETURNING ROWID INTO 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);

Servidor de Mensajería

Base de datos Oracle

Mensajes Outbound Mensajes Inbound XML

Grabación Oracle Mensajería Inbound

(32)

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.

(33)

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>^~\&amp;</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))

(34)

) )

), 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 misma s, sino también para disminuir los posibles errores.

(35)

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].

View publication stats View publication stats

Referencias

Documento similar

• Aplicación de los estándares en sistemas automatizados de gestión para la organización y recuperación de la información documental bibliográfica.. COMPETENCIAS GENERALES

Por su parte, la Organización Panamericana para la Salud, utilizó los Sistemas de Información Geográfica como herramienta para monitorear las desigualdades de salud en

2001 – Blue Cross and Blue Shield of Florida creó a The Blue Foundation for a Healthy Florida como una organización benéfica sin fines de lucro para promover una mejor salud en

La importancia otorgada a la percepción social en los sistemas salud en base a la concepción que se desarrolla a partir de las propuestas salubristas de la Organización Mundial de