Universidad de Valencia Universidad de Valencia

Universidad Politécnica de Valencia

Diseño de una interfaz para la integración automatizada de la información obtenida de un dispositivo cardiaco implantado (marcapasos) en la historia clínica electrónica del paciente, implementando el perfil IHE-PCD-IDCO.
TRABAJO FIN DE MASTER Trabajo de Investigación

Presentado por: Álvaro Cortes Mánica PARA OBTAR AL GRADO DE MAGISTER EN INGENIERÍA BIOMÉDICA

Dirigido por: Dr. Juan Miguel García Gómez

Valencia, España 2012

Resumen

RESUMEN
Estamos viviendo una época donde la información clínica es compleja y dispersa, por lo cual los profesionales de la salud a menudo usan una variedad de sistemas informáticos para obtener una historia clínica completa, centralizada y estructurada. Mientras el sector salud avanzan hacia un único objetivo de un registro amplio de historia clínica completa, su gran barrera es la de conseguir que diferentes sistemas informáticos médicos puedan comunicarse, permitiendo la interoperabilidad e intercambio de datos para una mejor gestión y seguimiento del paciente. En la actualidad una gran variedad de parámetros como los signos vitales, terapias de infusión, eventos de alarmas y otros datos que son obtenidos desde dispositivos médicos como marcapasos, son realmente críticos y necesarios para el seguimiento del estado del paciente, permitiendo una buena planificación y evaluación del tratamiento aplicado, además de monitorizar al paciente ya sea desde la comodidad de su casa o en una sala de cuidados intensivos donde se haga uso de estos equipos médicos. Por lo cual esta falta de datos en la historia clínica electrónica pudiera representar un problema grave, evitando que los clínicos tengan un acceso oportuno o inclusive imposible sobre el historial del paciente, provocando que no se pudiera dar la atención segura y eficaz que se requiere. El presente trabajo se desarrolla una interfaz que nos permite la integración automática de datos procedentes de un dispositivo cardiaco implantable (marcapasos), de manera automática, basándose en la metodología creada por la asociación IHE (Integrating the Healthcare Enterprise), específicamente usando el perfil, IHE-PCD-IDCO, el cual nos provee de un marco de trabajo basado en estándares internacionales como el de mensajería HL7, para solucionar problemas de interoperabilidad entre dispositivos cardiacos implantables y sistemas gestores de información clínica. Para llevar a cabo esta investigación, fue necesario consultar a doctores especialistas en el área de cardiología, para poder tener un mejor conocimiento sobre el flujo de trabajo que se requiere en este proceso clínico. Esta información obtenida fue importante, permitiendo poder diseñar un plan y una metodología a seguir. Para el desarrollo del proyecto se investigó sobre los diferentes sistemas integradores que actualmente están en el mercado y sobre las herramientas existentes en el ámbito de integración de sistemas médicos. Se evaluaron dos tipos distintos de sistemas integradores, siendo el software IGUANA de la empresa INTERFACEWARE el finalmente usado, por su fácil manejo y facilidades proporcionadas para cumplir con los requerimientos que el proyecto requería. Se estudió a detalle el protocolo HL7 versión 2.5, usado para el intercambio de información entre los sistemas médicos. El tipo de mensaje usado fue ORU (unsolicited laboratory test), pues dentro del marco teórico del perfil IHE-PCD-IDCO, se especifica que este mensaje debe ser usado como protocolo de intercambio de información. La información obtenida desde el marcapasos, siguiendo la normativa

Resumen

del IHE-PCD-IDCO, el cual menciona que los datos extraídos de un marcapasos deben de estar con la nomenclatura IEEE11073-10103. Por tal motivo fue necesario aprender a detalle este protocolo para posteriormente generar el mensaje HL7 específico. Como resultado, se consiguió generar un módulo de mapeo para preparar el mensaje ORU a partir de datos extraídos del marcapasos mediante el lenguaje LUA interpretado por IGUANA. Para simular un ambiente real de este proceso clínico, se decidió usar un software gestor de información clínica de licencia libre llamado “Open Clinic”, con tecnología Web, adaptándolo de tal manera que se puedan visualizar los datos extraídos desde el marcapasos en la sección del historial clínica del paciente desde cualquier navegador. Los resultados fueron muy positivos permitiendo cumplir con los requerimientos establecidos en la metodología del perfil IHE-PCD-IDCO, además de que la interfaz creada fue lo más transparente posible hacia al usuario, si necesidad de introducir datos o navegar por varias pantallas, era necesario simplemente un archivo de entrada.

Tabla de contenidos

Tabla de Contenidos.
1. Introducción. .................................................................................................................. 1 1.1 Anatomía del Corazón................................................................................................................................. 1 Funcionamiento del corazón. ......................................................................................................... 1 Sistema eléctrico del corazón. ....................................................................................................... 3 Alteraciones del ritmo cardiaco. .................................................................................................... 4 Componentes de un marcapasos. ............................................................................................... 5 Funcionamiento..................................................................................................................................... 6 Tipos de Marcapasos. ........................................................................................................................ 7 Marcapasos temporales. ......................................................................................................... 7 Marcapasos Permanentes. .................................................................................................... 7

1.1.1 1.1.2 1.1.3 1.2

Historia del Marcapasos. ............................................................................................................................ 5

1.2.1 1.2.2 1.2.3

1.2.3.1 1.2.3.2 1.2.4 1.2.5 1.2.6 1.3

Conceptos de Marcapasos. ........................................................................................................... 8 Nomenclatura. ........................................................................................................................................ 8 Nueva generación de marcapasos. ............................................................................................ 9 Sistemas gestores de información cardiológica. ............................................................... 11 Sistemas de seguimiento remoto. ................................................................................... 12 Biotronik Home Monitoring. ................................................................................................ 14 Medtronics Paceart. ................................................................................................................ 15 Soluciones comerciales. ................................................................................................................ 14

Programadores y fabricantes de marcapasos. ............................................................................ 10

1.3.1

1.3.1.1 1.3.2

1.3.2.1 1.3.2.2 2

Justificación. ................................................................................................................ 17 2.1 Objetivos. ........................................................................................................................................................ 18 Objetivo General. ............................................................................................................................... 18 Objetivos Específicos. ..................................................................................................................... 19

2.1.1 2.1.2 3.

Metodología. ................................................................................................................ 20 3.1 IHE (Integrating the Healthcare Enterprise). ................................................................................. 20 Dominios del IHE............................................................................................................................... 21 Cómo funciona los perfiles del IHE. ......................................................................................... 21 Perfiles del dominio IHE-PCD(Patient Care Device) ....................................................... 24

3.1.1 3.1.2 3.2

Dominio IHE-PCD (Patient Care Device). ...................................................................................... 23 Perfil IHE-PCD-IDCO (Implantable Device Cardiac Observation). .................................... 25

3.2.1 3.3

Tabla de contenidos

3.3.1 3.3.2 3.3.3 3.3.4

Introducción.......................................................................................................................................... 25 Actores y transacciones................................................................................................................. 26 Descripción funcional ...................................................................................................................... 27 Estándares............................................................................................................................................ 28 HL7 V2.5x ORU ........................................................................................................................ 28

3.3.4.1

3.3.4.1.1 Componentes de un Mensaje HL7 ............................................................................. 28 3.3.4.1.2 Caracteres delimitadores en HL7 ................................................................................ 29 3.3.5 Proceso de trabajo del IHE-PCD-IDCO. ................................................................................ 29 IEEE 11073_10103. ............................................................................................................... 30 Mensaje HL7/ORU. ............................................................................................................... 32 Consideraciones de Identificación del paciente. ............................................................... 31

3.3.5.1 3.3.6

3.3.7.1

3.3.7.1.1 Segmento MSH – Cabecera del Mensaje. ............................................................. 33 3.3.7.1.2 Segmento PID – Identificación del Paciente. ........................................................ 36 3.3.7.1.3 Segmento PV1– Visita del Paciente (Opcional). ................................................ 38 3.3.7.1.4 Segmento OBR– Solicitud de Observación. .......................................................... 39 3.3.7.1.5 Segmento OBX– Resultado de las Observaciones. .......................................... 40 3.3.7.1.6 Segemento NTE– Comentarios y Notas (Opcional).......................................... 42 3.3.7.2 3.3.7.3 4. Mensaje de Autentificación (ACK). ................................................................................. 43 LLP- Lower Layer Protocol. ............................................................................................... 44

Soluciones Planteadas. ............................................................................................... 46 4.1 Casos de uso. ............................................................................................................................................... 46 En el hospital. ...................................................................................................................................... 46 Remoto. .................................................................................................................................................. 46

4.1.1 4.1.2 4.2 4.3

Identificación de actores.......................................................................................................................... 48 Diseño del actor DOR(Device Cardiac Reporter)...................................................................... 50 Mirth. ........................................................................................................................................................ 51 Iguana. .................................................................................................................................................... 53 Diseño de canales de entrada. ......................................................................................... 55

4.3.1 4.3.2

4.3.2.1

4.3.2.1.1 Datos de entrada del canal. ........................................................................................... 55 4.3.2.1.2 Datos de Salida del canal. .............................................................................................. 55 4.3.2.1.3 Identificación del Paciente. ............................................................................................. 57 4.3.2.1.4 Flujo de trabajo del actor DOR. .................................................................................... 58

Tabla de contenidos

4.4

Diseño del actor DOC(Device Cardiac Consumer) .................................................................. 59 Datos de entrada del canal. ......................................................................................................... 59 Datos de salida del canal. ............................................................................................................. 60 Chamaleon.................................................................................................................................. 61 Flujo de trabajo del actor DOC. ........................................................................................ 63

4.4.1 4.4.2

4.4.2.1 4.4.2.2 4.5

Sistema gestor de historia clínica OpenClinic .............................................................................. 64 Servidor Web Apache. .................................................................................................................... 65 Arquitectura del servidor Apache. ................................................................................... 65 Interfaz OpenClinic. .......................................................................................................................... 66 Base de datos del software OpenClinic. ................................................................................ 68 Modificaciones realizadas a OpenClinic. ............................................................................... 69

4.5.1

4.5.1.1 4.5.2 4.5.3 4.5.4 5.

Resultados. .................................................................................................................. 71 5.1 Sistema OpenClinic. .................................................................................................................................. 72

6 7

Conclusiones. .............................................................................................................. 80 Anexos ......................................................................................................................... 82

Nomenclatura IEEE 11073 MDC_IDC ...................................................................................................................... 82 Archivo de entrada usado como ejemplo con la Nomenclatura IEEE 11073 MDC_IDC...................111 Algoritmo LUA creado para el transformador del sistema integrador IGUANA ..................................117 Lista de figuras ................................................................................................................................................................133 Lista de tablas..................................................................................................................................................................134

Introducción

1. INTRODUCCIÓN. 1.1 Anatomía del Corazón.

El corazón se encuentra entre los pulmones en el centro del pecho, detrás y levemente a la izquierda del esternón. Una membrana de dos capas, denominada pericardio envuelve el corazón como una bolsa. La capa externa del pericardio rodea el nacimiento de los principales vasos sanguíneos del corazón y está unida a la espina dorsal, al diafragma y a otras partes del cuerpo por medio de ligamentos. Una capa de líquido separa las dos capas de la membrana, permitiendo que el corazón se mueva al latir a la vez que permanece unido al cuerpo. En la anatomía del corazón podemos encontrar cuatros cavidades, en las cuales, las cavidades superiores se denominan aurícula izquierda y aurícula derecha y las cavidades inferiores se denominan ventrículo izquierdo y ventrículo derecho. También cuenta con una pared muscular denominada tabique, que separa las aurículas izquierda y derecha y los ventrículos izquierdos y derecho. El ventrículo izquierdo es la cavidad más grande y fuerte del corazón, de igual manera el ventrículo izquierdo tienen un grosor de sólo media pulgada (poco más de un centímetro), pero tienen la fuerza suficiente para expulsar la sangre a través de la válvula aórtica hacia el resto del cuerpo (Figura 1.1)[1]. 1.1.1 Funcionamiento del corazón. La aurícula derecha recibe la sangre con poco oxígeno de todo el cuerpo y, con su contracción, la inyecta en el ventrículo derecho. Esta cavidad se contrae y manda su contenido, a través de la arteria pulmonar, a los pulmones, donde se carga del oxígeno que respiramos. La sangre ya oxigenada en el pulmón pasa a la aurícula izquierda y, de ésta, al ventrículo izquierdo. Desde esta cavidad, a través de la arteria aorta, se bombea llegando a todo el organismo. La contracción de ambas aurículas es simultánea y lo mismo sucede con ambos ventrículos, cuya contracción sucede tras la de las aurículas, una vez que ambos se han llenado [2]. La tabla siguiente muestra los elementos que conforman la anatomía del corazón, así como una descripción de su funcionamiento.

1

Introducción

Tabla 1.1. Componentes del corazón Función En la aurícula derecha desembocan la vena cava superior, la vena cava inferior, y el seno coronario Aurícula izquierda Recibe sangre oxigenada proveniente de los pulmones y la impulsa a través de la válvula mitral hacia el ventrículo izquierdo, el cual la distribuye a todo el organismo mediante la arteria aorta Válvulas cardiacas: tricúspide, pulmonar, Su función es poder mantener aislado por un aórtica, y mitral. instante el flujo sanguíneo en alguna de las cuatro cavidades. Con las diferentes contracciones del corazón, se contraen también en una secuencia determinada las cuatro cavidades, bombeando la sangre en una dirección. Sin las válvulas, la sangre volvería a la cavidad después de la contracción Vena cava superior Es un tronco venoso o vena de gran calibre que recoge la sangre de la cabeza, el cuello, los miembros superiores y el tórax. Retorna la sangre de todas las estructuras que quedan por encima del músculo diafragma con excepción de los pulmones y el corazón. Ventrículo derecho El ventrículo derecho recibe la sangre no oxigenada de la aurícula derecha por medio de la válvula tricúspide y la impulsa fuera del corazón a través de la arteria pulmonar. Ventrículo izquierdo Es la porción del corazón con mayor cantidad de tejido muscular debido a que el ventrículo izquierdo es quien impulsa la sangre hacia la arteria aorta, la cual lleva sangre a la mayor parte del cuerpo. Aorta Es la principal arteria del cuerpo humano La función de la aorta es transportar y distribuir sangre rica en oxígeno todo el cuerpo. Arteria pulmonar Es la arteria por la cual la sangre pasa del ventrículo derecho a los pulmones, para ser oxigenada. Vena pulmonar Son el conjunto de venas encargadas de transportar la sangre oxigenada desde los pulmones al corazón. Se trata de las únicas venas del organismo que transportan sangre oxigenada. Vena cava inferior Retorna la sangre de los miembros inferiores, los órganos del abdomen y la pelvis hasta la aurícula derecha del corazón Nombre Aurícula derecha

2

Introducción

Figura 1.1. Anatomía del Corazón 1.1. Figura 1.1 1.1 Ilustración Anatomía del Corazón.

1.1.2 Sistema eléctrico del corazón. Como se mencionó anteriormente el corazón es el órgano central del sistema cardiovascular. Se divide en dos compartimientos o cavidades superiores, las aurículas y dos compartimientos inferiores, los ventrículos. Su función es proveer al cuerpo la sangre y el oxígeno que necesita para funcionar correctamente, para esto, el corazón se encuentra dotado de movimientos o latidos rítmicos generados por impulsos eléctricos producidos por un sistema de excitación y conducción especializado [3]. Los impulsos eléctricos se generan en el nódulo sinusal o nódulo sinoauricular, que es una pequeña área de tejido especializado localizada en la aurícula derecha del corazón (la cavidad superior derecha). En condiciones normales, el nódulo sinusal genera un estímulo eléctrico cada vez que late el corazón de 60 a 190 veces por minuto, dependiendo de la edad de la persona y de su nivel de actividad. Este impulso eléctrico viaja desde el nódulo sinusal hasta el nódulo aurículo ventricular (AV), donde se retrasan el impulso durante un breve instante y después viaja a través de un sistema llamado haz de His con dirección hacia los ventrículos. El haz de His se divide en la rama derecha y en la rama izquierda, y este a su vez en microscópicas ramificaciones de fibras miocárdicas (Red de Purkinje) que son excitadas produciendo el estímulo eléctrico a los dos ventrículos [4]. Cada contracción de los ventrículos representa un latido. Las aurículas se contraen una fracción de segundo antes que los ventrículos para que la sangre que contienen se vacíe en los ventrículos antes de que éstos se contraigan. La figura 1.2 muestra el sistema eléctrico del corazón, así como los elementos que intervienen para la generación del pulso cardiaco.

3

Introducción

Figura 1.2. Sistema eléctrico del corazón

1.1.3 Alteraciones del ritmo cardiaco. Cualquier irregularidad en el proceso de generación y conducción de las señales eléctricas descritas con anterioridad origina un trastorno del ritmo cardiaco. En general, las alteraciones del ritmo se pueden deber a dos tipos de procesos: anomalías en la formación del impulso eléctrico o bien anomalías en la conducción de dicho impulso. Cuando el corazón no late a una frecuencia constante los episodios son llamados arritmias. Si el latido del corazón es demasiado lento se llama bradiarritmia o bradicardia. Si es demasiado rápido se llama taquiarritmia o taquicardia. En lo relativo a la velocidad de los latidos, se diferencian las bradicardias, que corresponden a frecuencias cardiacas lentas, (por debajo de los 60 latidos por minuto); y las taquicardias, que son arritmias con frecuencias cardiacas muy rápidas, (superior a 100 latidos por minutos) [5]. Algunas arritmias que ocurren con más frecuencia son:      Taquicardia supra ventricular o paroxística. Síndrome del seno enfermo. Fibrilación Auricular. Taquicardia ventricular. Fibrilación ventricular.

Con el avance de la tecnología, hoy en día se pueden corregir estas patologías, y conseguir que la persona tenga una vida normal, y que sigan realizando sus actividades diarias. Para eso es necesario el uso de los marcapasos que de manera general son pequeños dispositivos electrónicos con una función específica, son implantados debajo de la piel, cerca del corazón. Es dispositivos monitorizan el corazón y detectan cualquier ritmo anormal (arritmias). Si alguna de estas arritmias es maligna, el marcapasos produce una descarga eléctrica para restablecer el ritmo cardiaco normal. En la siguiente sección se explica a más detalle el funcionamiento y los tipos de marcapasos existentes en el mercado actual.
4

Introducción

1.2

Historia del Marcapasos.

Un marcapasos es un pequeño dispositivo electrónico generador de impulsos que excitan artificial y rítmicamente el corazón cuando los marcapasos naturales del corazón no pueden mantener el ritmo y la frecuencia adecuada. Además estos dispositivos monitorizan la actividad eléctrica cardiaca espontánea, y según su programación desencadenan impulsos eléctricos o no. Pueden ayudar a regular el ritmo del corazón en casos de frecuencia cardíaca lenta, rápida o irregular, o de bloqueo en el sistema de conducción eléctrica del corazón. Hyman en el año de 1932 fue el primero que estimuló el corazón con un generador de impulsos externo (que cargaba manualmente con una manivela) mediante unos cables transtorácicos hasta el corazón, pero fue el Dr. Senning, en 1958, quien inició la estimulación cardiaca con el marcapasos tal como se entiende hoy día, con el generador de estímulos implantado dentro del cuerpo, y el uso de baterías para su funcionamiento. Las primeras baterías utilizadas fueron de níquel‐cadmio, que sustituidas posteriormente por las de mercurio‐zinc y finalmente por las de litio, consiguiéndose un tamaño mucho más pequeño[6]. 1.2.1 Componentes de un marcapasos. La figura 1.3 siguiente muestra de manera general los componentes de un marcapasos.

Figura 1.3. Componentes de un marcapasos genérico.

Un generador de impulsos: El generador produce las señales eléctricas que hacen que el corazón lata. Muchos generadores de pulsos son capaces también de recibir las señales que envía el propio corazón y de responder a ella, en esta sección se encuentra también la batería y circuitos electrónicos. Actualmente se usan baterías de Litio que permiten mayor duración, confianza y predictibilidad de su agotamiento.
5

Introducción

Un cable destinado a la conducción de dichos impulsos: Los conductores son cables flexibles aislados que llevan las señales eléctricas desde el generador de pulsos hasta el corazón y que también pueden transmitir señales desde el corazón hasta el generador de pulsos. Electrodos: Son la porción terminal de los cables en contacto con el corazón, bien con su superficie interna (endocardio) o con la externa (epicardio). Según las necesidades del paciente, el marcapasos puede tener uno, dos o tres electrodos.

1.2.2 Funcionamiento.

Figura 1.4. Figura de un marcapasos implantado

El marcapasos se implanta cerca de la clavícula, si sólo se necesita un electrodo, éste se coloca en la cavidad inferior derecha (el ventrículo derecho). Si se necesitan dos electrodos, el segundo se coloca en la cavidad superior derecha (aurícula derecha). A continuación, se conectan los electrodos al marcapasos (ver figura 1.4). La mayoría de las intervenciones de implantación de marcapasos se realizan bajo anestesia local, es decir que el paciente permanece despierto durante el procedimiento y se anestesia la zona donde se implantará el marcapasos para que no sienta nada. El procedimiento típicamente dura una o dos horas. Una vez implantado el marcapasos, los electrodos transmiten las señales generadas por el corazón. El generador de impulsos lee estas señales y si existiera un problema con el ritmo cardiaco, este envía impulsos eléctricos al corazón para estimularlo rítmicamente. La mayoría de los marcapasos pueden detectar el ritmo cardíaco y apagarse cuando la velocidad de los latidos es superior a un nivel determinado.

6

Introducción

1.2.3 Tipos de Marcapasos. La estimulación eléctrica de un marcapasos puede ser temporal o permanente, dependiendo de si el origen del trastorno que llevó a su utilización es reversible o permanente. 1.2.3.1 Marcapasos temporales.

Se utilizan en situaciones de emergencia, en casos de alteraciones transitorias de la conducción del sistema eléctrico del corazón. El generador no está implantado en el paciente, existen varios tipos: •    Transcutáneos : Los electrodos se colocan sobre la piel, uno en la parte anterior del tórax (electrodo negativo) y otro en la espalda (electrodo positivo, rojo). Intravenoso: Los electrodos son colocados a través de una vía central hasta contactar con el endocardio. Transtorácico: Los electrodos son directamente colocados en las paredes auricular y/o ventricular durante la cirugía, que se conectan a un generador externo. Transesofágico: Se coloca un electrodo en el esófago y otro precordial. Es una técnica difícil, y sólo se usa para el diagnóstico de taquicardias [6]. Marcapasos Permanentes.

1.2.3.2

Se implantan en el tejido subcutáneo del tórax debido a un problema de conducción permanente del sistema eléctrico del corazón. Existen varios tipos: • Transvenosos: Los electrodos se colocan a través de una vena subclavia y se implantan en aurícula y/o ventrículo derecho. El generador se coloca de manera subcutánea en la región infra clavicular. Internos: Los electrodos se colocan directamente en la pared auricular y/o ventricular, el generador se coloca de manera subcutánea en la pared abdominal [6].

Figura 1.5. Marcapasos de la empresa ST. Jude Medical.

7

Introducción

La figura 1.5 muestra una imagen de un marcapasos comercial de la empresa ST. Jude Medical. 1.2.4 Conceptos de Marcapasos. • Intensidad o amplitud (OUT‐PUT): Es la intensidad del estímulo eléctrico generado por el marcapasos. Su valor ha de ajustarse para que sea capaz de despolarizar el miocardio. • Sensibilidad: El marcapasos reconoce la actividad eléctrica espontánea del corazón desde un umbral que nosotros programamos, que se denomina sensibilidad y se expresa en mili voltios. • Frecuencia: Es la frecuencia de estimulación programada del marcapasos, si la frecuencia cae por debajo de ese valor, el marcapasos comienza a funcionar. • Intervalo aurículo ventricular: Es el tiempo en milisegundos entre la estimulación auricular y la ventricular. Debe cambiarse según la frecuencia programada en el marcapasos, algunos marcapasos la ajustan automáticamente. Entre 50 y 300 milisegundos. • Seguimiento auricular: Es la capacidad del marcapasos de estimular el ventrículo después de una onda auricular espontánea, una vez transcurrido el intervalo aurículo ventricular programado [6]. 1.2.5 Nomenclatura. Para entender la nomenclatura de un marcapasos la asociación ICHD (Inter Society Commission for Heart Diseases Resources) establece un código de cinco letras que clasifica los marcapasos según los puntos de estimulación y funciones. La siguiente tabla muestra los valores posibles de la clasificación de los marcapasos. Como ejemplo podemos guiarnos de la siguiente plantilla XYZ AB, la cual indica la posición y el valor que puede tomar esa posición.

8

Introducción

Tabla de nomenclatura de marcapasos Posición X Nombre Estimulación: Identifica la cámara estimulada Valores 0 Ninguna A Aurícula V Ventrículo D Doble S Single (denominación de fábrica) 0 Ninguna A Aurícula V Ventrículo D Doble S Single (denominación de fábrica) 0 Ninguna T Disparado I Inhibido D Disparado + inhibido 0 Ninguna C Comunicación, telemetría P Mono o biprogramable M Multiprogramable R Frecuencia variable 0 Ninguna P Estimulación S Choque D Estimulación + choque

Y

Detección: Identifica la cámara censada.

Z

Respuesta: El modo de respuesta del marcapasos.

A

Programabilidad: Indica las funciones programables.

B

Anti taquicardia: Funciones programables de anti taquicardia.

1.2.6 Nueva generación de marcapasos. Tras la aparición del transistor, los marcapasos incorporaron esta tecnología, lo que permitió reducir su tamaño y a la vez incrementar su duración por reducción del consumo interno. Posteriormente, la aplicación de circuitos híbridos semi-integrados e integrados y de la tecnología CMOS en los generadores, permitió progresar en la reducción del consumo y tamaño de los mismos. En la actualidad la tecnología de los marcapasos se basa en circuitos integrados y micro-procesadores, cada vez con mayor capacidad de memoria. Además, en algunos casos es posible ampliar las funciones disponibles de uno ya implantado, por medio de telemetría y descarga de un nuevo software. La programación de los marcapasos actualmente son en dos direcciones: del especialista hacia el marcapasos y del marcapasos al especialista, mediante ondas electromagnéticas (telemetría) y no mediante campos magnéticos como se hacía anteriormente. Esta comunicación bidireccional, llamada programador-marcapasos-marcapasosprogramador ha permitido también confirmar la modificación de las características del marcapasos. Otro paso importante fue cuando aparecieron los sensores, detectores de un cierto parámetro metabólico o físico de la persona, que informan al
9

Introducción

marcapasos de la frecuencia cardiaca necesaria en aquel momento para el funcionamiento normal del organismo [6].

1.3

Programadores y fabricantes de marcapasos.

Los programadores son las herramientas encargadas de comunicarse con el marcapasos para extraer los datos así como modificar las configuraciones de funcionamiento del dispositivo. Estos programadores cuentan con software específico y hardware adaptado que permiten el intercambio de la información encriptada contenida en el marcapasos. Utiliza telemetría bidireccional para recibir y modificar dicha información. De este modo, se comprueba el estado de los diferentes parámetros del mismo y de los electrodos, pudiéndose también realizar si es preciso otras comprobaciones como medición de umbrales, reprogramaciones, etc. Una de las comprobaciones realizadas es relativa a la batería del dispositivo implantado, cuya variación depende del tipo de dispositivo, de las funciones activadas, de la utilización del mismo por parte del paciente en función de su patología. Cuando la batería se agota, es necesario reemplazar el dispositivo, manteniéndose normalmente los electrodos previamente implantados [5]. Existen varias empresas manufactureras encargadas de fabricar marcapasos, cada casa comercial, tiene sus propios modelos con funcionalidades diferentes. La tabla siguiente muestra las principales empresas que producen marcapasos.
Tabla 1.2. Empresas manufactureras de marcapasos.

Nombre de la Empresa
Angeion Corp. Boston Scientific Cardio-Pace Medical Cordis Intermedics Medtronic Pacesetter Sorin Teletronics American Pacemaker Corp. Cardiac Control Systems Cook Pacemaker Corp. ELA Medical Implantronik Oscor Siemens St.Jude Medical Ventritex Biotronik Cardiac Impulse Coratomic Inc. Guidant Medico Osypka Somedics Stoeckert Vitatron

10

Introducción

La información obtenida por medio de los programadores es muy importante, y es la que el médico analiza para poder dar un diagnostico al paciente, cada programador funciona y extrae la información de diferente manera, a pesar de ser de la misma casa comercial. La mayoría de estos programadores son sistemas con tecnología stand-alone donde tienen incorporado una pequeña pantalla, y se pueden visualizar los datos extraídos, pueden contar con algunos puertos periféricos como serial, USB, paralelo para el intercambio de información, e inclusive la opción de impresión (Figura 1.6). En la actualidad con el avance de la tecnología, estos han avanzado hasta poder comunicarse con ordenadores para descargar y posteriormente analizar la información, que por medio de un software instalado en el ordenador se puede acceder a todas las funciones del marcapasos de manera fácil e intuitiva.

Figura 1.6. Programador Medtronic CareLink

1.3.1 Sistemas gestores de información cardiológica. Los sistemas gestores de información cardiológica de marcapasos son aplicaciones de software que organizan la información extraída del marcapasos por medio del programador, así como la información personal (datos demográficos) de los pacientes, con la finalidad de tener un registro continuo y actualizado sobre todos los eventos ocurridos en el dispositivo cardiaco implantado. De esta manera se puede tener un historial actualizado en todo momento, para ofrecer un mejor servicio sanitario de calidad. Estos sistemas debido a que funciona sobre ordenadores, hacen uso de muchas de sus características actuales, como el uso conexiones con otros sistemas informáticos mediante el protocolo TCP/IP, por ejemplo, la comunicación con un sistema de gestión clínica, para obtener los datos demográficos del paciente y asociarlos con los datos extraídos del marcapasos (ver figura 1.7).

11

Introducción

Programador Paciente Doctor
Figura 1.7. Flujo de trabajo de un sistema gestor de información cardiológica.

La principal funcionalidad de estos sistemas es que sirven como puerta de enlace, en el cual fluyen los datos extraídos de los programadores hacia un sistema informático de historia clínica electrónica. Estos sistemas pueden funcionar de manera remota permitiendo obtener datos desde el domicilio del paciente, de manera automática, segura y con las mismas características que se han mencionado anteriormente. El siguiente punto explica con más detalle cómo funciona este sistema de manera remota. 1.3.1.1 Sistemas de seguimiento remoto.

El fabricante distribuye un equipo, normalmente asignado de manera unívoca al marcapasos, que se instala en el domicilio del paciente. Esta instalación suele consistir en una conexión a la línea telefónica convencional y, algunos equipos funcionan con pilas, y otros permiten el envío de los datos mediante sistema GPRS, es decir, a través de un teléfono móvil (ver figura 1.8).

Figura 1.8. Equipos usados para la transferencia de datos de manera remota

Los sistemas de interrogación remota pueden funcionar en dos modos: • • Interrogación continuada. Interrogación programada.

12

Introducción

En el primer modo, el equipo del paciente debe estar permanentemente conectado, de forma que se produce una comunicación continua y de forma automática (vía inalámbrica) entre el equipo y el dispositivo con el fin de detectar la alteración en los valores de determinados parámetros prefijados. En el segundo modo, el equipo puede estar conectado únicamente en las fechas programadas por el personal facultativo para la interrogación. Este programa de interrogaciones correspondería al calendario de citas en la consulta presencial habitual. Al mismo tiempo, la interrogación del dispositivo en la fecha proyectada puede realizarse de forma manual o automática, utilizando una conexión inalámbrica entre el dispositivo y el equipo del domicilio. En el primer caso, el proceso es iniciado por el propio paciente, generalmente a cualquier hora del día. En el caso de las interrogaciones automáticas, el equipo intenta conectar con el dispositivo en la fecha especificada, comenzando normalmente en las primeras horas del día, y repitiendo esta operación cada ciertos periodos de tiempo (entre 2 y 3 horas), hasta que termina con éxito la interrogación. Una vez que se han obtenido todos los datos, el equipo envía la información a un servidor propiedad del fabricante del dispositivo. Si se trata de información correspondiente a una interrogación programada o solicitada específicamente por el personal sanitario, estos datos quedan almacenados en el servidor para ser consultados por el clínico a través de Internet (ver figura 1.9). Además de transmitirse la información al servidor, en algunos casos se da un aviso de alarma al centro médico en la forma que se haya estipulado: un mensaje de correo electrónico, un mensaje al teléfono móvil, etc [5].

Figura 1.9. Flujo de trabajo de un sistema de seguimiento remoto

13

Introducción

1.3.2 Soluciones comerciales. Existen varias soluciones en el área de gestores de información de datos de marcapasos, que van con características desde poder comunicarse y compartir datos de los programadores con la mayoría de las marcas existentes, contando con características de seguimiento remoto, servicios de cloud-compunting, integración automática en la historia clínica electrónica, así como módulos para conexión e intercambio de información con otros sistemas informáticos. Los más conocidos son desarrollados por las empresas Biotronik y Medtronics, que a continuación se explican brevemente. 1.3.2.1 Biotronik Home Monitoring.

EL sistema Home Monitoring es una plataforma web de monitorización, el cual hace uso de la tecnología de la red móvil para el intercambio de los datos, permitiendo a los médicos monitorizar en todo momento el estado actual de sus pacientes, así como la configuraciones de sus marcapasos, esto sin importar donde se encuentren. Su funcionamiento es muy sencillo. El marcapasos trasmite de manera inalámbrica, automática y silenciosa sus datos, a un pequeño sistema de comunicación, que se encuentra instalado en el domicilio del paciente. Este pequeño sistema de comunicación recibe los datos y de manera rápida los envía al servidor central de la empresa BIOTRONIK, usando las redes de comunicación de la telefonía celular. (Ver figura 1.10)[7].

Paciente

Sistema de Aplicación Servidor Doctor comunicació Web BIOTRONIK n Figura 1.10. Arquitectura del sistema BIOTRONIK Home Monitoring

El servidor central de BIOTRONIK, una vez que recibe estos datos los analiza y actualiza el registro actual del paciente en una base de datos propia, con los eventos provenientes del marcapasos, para su posterior consulta. Es aquí cuando el médico se conecta al servidor, mediante una aplicación Web, para poder visualizar el estado de sus pacientes. En caso de que existieran eventos que requieran de una atención de emergencia, este sistema genera inmediatamente una notificación, que puede ser enviada automáticamente por email o inclusive un SMS a los médicos para avisarles de las condiciones del paciente en ese momento.

14

Introducción

1.3.2.2

Medtronics Paceart.

Es un sistema gestor de información cardiológica, en donde se organiza la información principal de los pacientes, así como toda la información de configuración tanto del programador del marcapasos, como también la configuración del mismo marcapasos. Esto sin duda es un gran beneficio para el personal sanitario, pues ofrece la posibilidad de visualizar los datos en cualquier momento, y conocer en todo momento el estado actual de los pacientes. La característica principal de este sistema es que puede comunicarse con la mayoría de los programadores existentes, permitiendo compartir la información, sin necesidad de tener que realizar adaptaciones o aplicaciones, para cada programador específico de cada empresa. Otra característica importante, es que puede hacer uso de la información desde un sistema remoto, gestionando la información del paciente desde el domicilio propio del paciente. La figura 1.11 muestra el funcionamiento del sistema Paceart.

Figura 1.11. Funcionamiento del sistema Paceart de Medtronics.

Igual que el sistema Home Monitoring, cuenta con los servicios de base de datos para la gestión de los datos, así como características de cloud-computing, generación de reportes, agendas de pacientes. Una cosa importante que se debe mencionar, es que estos sistemas gestores nos ofrecen la información ya procesada desde el programador de manera que pueda ser entendible por el médico. Es por eso que si se requiere de utilizar la información obtenida del marcapasos, para integrarla a otros sistemas como es en nuestro
15

Introducción

objetivo en este proyecto, estos sistemas ofrecen un salida de datos que generalmente es en formato XML, con un protocolo establecido (IEEE 11073 10103 - MDC-IDC) donde se visualizan los datos y eventos cardiacos de una manera fácil de entender. Está muy claro que sin estos sistemas es imposible obtener los datos desde el marcapasos, debido a que los programadores manejan protocolos y estándares propios de comunicación que son muy difíciles de entender.

16

Justificación

2 Justificación.
La Historia Clínica Electrónica (HCE) de un paciente debe ser completa, por lo que debe tener la capacidad de registrar toda la información que surge de cada acto médico durante toda la vida del paciente. Para lograrlo se debe elegir cuidadosamente el modelo de información que se usará para almacenar toda la información clínica. Por lo cual la falta de datos en la historia clínica electrónica pudiera representar un problema grave, evitando que los médicos tengan un acceso oportuno o inclusive imposible al historial del paciente, provocando que no se pudiera dar la atención segura y eficaz que se requiere [8]. La solución a este problema puede ser resuelta mediantes el uso de sistemas o aplicaciones basados en estándares que nos permitan resolver el intercambio de información (interoperabilidad) con otros sistemas o aplicaciones. Es por eso que en este proyecto se desarrolla una interfaz que sea capaz de obtener los datos contenidos en un marcapasos, para registrarlos en la historia clínica electrónica del paciente de manera automática, sin importar la ubicación del paciente, siguiendo una metodología internacional ofrecida por la asociación IHE (Integrating the Healthcare Enterprise), líder en el campo de la interoperabilidad de sistemas médicos. Permitiendo los siguientes beneficios:  Los perfiles de integración IHE permiten gestionar de un modo eficaz el conjunto integrado de sistemas de información necesario para proporcionar una atención sanitaria de calidad. La integración a través de estos perfiles es menos costosa desde el principio y hace que resulte más fácil la planificación y puesta en marcha de futuras adquisiciones, además de ser más productiva al proporcionar capacidades valiosas. Los perfiles de integración definen claramente cómo deben encajar todas las piezas basándose en estándares aceptados globalmente. La asociación IHE hace que el uso de las tecnologías de la información avanzadas ayude en gran medida al personal sanitario a la hora de mejorar la calidad y eficiencia de la atención sanitaria. IHE aumenta la seguridad del paciente al garantizar la integridad de la información médica. Igualmente reduce el tiempo empleado en la solución de problemas tales como la pérdida de datos y la aparición de estudios no correspondientes, optimizando así el aprovechamiento de tiempo del personal. Proporciona de igual manera al personal sanitario información bien estructurada sobre el paciente de modo que la toma de decisiones médicas se base en la mejor información posible. pacientes sean capaces de crear, gestionar y acceder a amplias historias clínicas electrónicas, de manera eficiente y segura. De esta manera integrando los perfiles de IHE, se mejora el intercambio de información
17

 El cuidado óptimo del paciente exige que los proveedores de salud y

Justificación

entre los sistemas de salud, permitiendo mejorar la calidad, eficiencia y seguridad de la atención clínica, facilitando la información de salud relevante de fácil acceso para los pacientes y proveedores de salud autorizados.

2.1

Objetivos.

Ingenieros biomédicos, clínicos y profesionales de las tecnologías de información en salud, son conscientes de la importancia de la integración de datos desde un dispositivo medico implantable hacia un sistema de historia clínica electrónica, y conocen la dificultad de conseguirlo debido a que las empresas manufactureras de dichos equipos mantiene en privacidad los datos que son extraídos de ellos, creando protocolos propios, haciendo uso de solamente algunos estándares oficiales, además permitiendo gestionar dicha información con su propio software, este hecho hace que cada compañía mantenga en secreto su tecnología, para así evitar los plagios industriales. Es por eso que en este proyecto se plantea el desarrollo de una interfaz de integración, el cual permite el flujo rápido, efectivo y transparente de los datos provenientes de los diferentes tipos de marcapasos existentes, hacia un sistema informático de historia clínica personal. Esta interfaz sin duda beneficiaría de la siguiente manera.  Mejor cuidado al paciente: Una historia clínica electrónica completa, ayuda a garantizar mejor atención sanitaria, permitiendo a los médicos conocer en todo momento el estado del paciente. Flujo de trabajo más eficiente: Facilita a los médicos el acceso ordenado a los datos en cualquier momento. Automatización de los datos de entrada: La integración automática de los datos, ayudaría a reducir los errores comúnmente asociados con un una entrada manual de datos.

 

Además de estos beneficios, la interfaz desarrollada permitirá integrar los datos de diferentes marcapasos de casas comerciales, siempre y cuando estos compartan la información con el estándar IEEE 11073 - 10103 - MDC-IDC. De manera que el coste de integración sería mínimo pues se haría uso de la misma interfaz desarrollada.

2.1.1 Objetivo General. Este proyecto tiene como objetivo principal el desarrollo de una interfaz, cuya funcionalidad es la integrar de manera automática los datos almacenados en dispositivos cardiacos implantables, para registrarlos en cualquier sistema gestor de historias clínicas electrónicas existentes, sin importar la arquitectura o el tipo de sistema operativo en el que estos sistemas operan (multiplataforma), haciendo uso
18

Justificación

de la metodología descrita en el perfil IHE-PCD-IDCO, usada para la comunicación e intercambio de información entre dispositivos de cuidado personal .

2.1.2 Objetivos Específicos. El software desarrollado debe cumplir con los siguientes requerimientos específicos:     Procesar la mayoría de los datos provenientes de los diferentes marcapasos existentes en el mercado. Los datos provenientes del marcapasos, pueden ser obtenidos desde el hospital o desde el domicilio del paciente. Pueda comunicarse con cualquier sistema gestor de historia clínica electrónica existente. Escalable a la incorporación de más módulos para comunicarse e intercambiar información con otros sistemas informáticos. Por ejemplo incorporar datos de otros tipos de dispositivos médicos de monitoreo. Sencillo y de fácil manejo para el integrador final. Fácil mantenimiento.

 

19

Metodología

3. M ETODOLOGÍA.
Por conveniencia, algunos términos, que intervienen en la metodología de estos dominios, serán escritos en su lenguaje original (ingles), esto con la finalidad de evitar confusiones en la traducción y además facilita el mejor entendimiento de la metodología. Como se ha mencionado anteriormente, esta investigación se basa en una metodología ofrecida por la asociación IHE (Integrating the Healthcare Enterprise), la cual soluciona los diversos problemas de interoperabilidad de sistemas informáticos médicos que existen en diferentes áreas de la medicina. Dentro de esta metodología existe un dominio (área) relacionado con los problemas de comunicación entre dispositivos médicos de cuidado personal llamado Personal Care Device (PCD), aquí es donde se encuentran las bases a seguir para realizar aplicaciones informáticas de interoperabilidad en el área de dispositivos de cuidado al paciente. En esta sección se ubica el perfil Implantable Device Cardiac Observation (IDCO), que es el que nos interesa ya que nos permite resolver la problemática inicial, que es la integración de los datos de un marcapasos hacia el historial clínico personal del paciente de manera automática. Este proyecto sigue la metodología descrita en el perfil Implantable Device Cardiac Observation (IDCO), el cual es un conjunto de documentos donde se especifica las normas a seguir. La siguiente sección del proyecto tiene como objetivo explicar las partes más importantes que están contenidas en estos documentos. Si se requiere más información específica sobre estas guías se puede consultar los siguientes enlaces:
 http://wiki.ihe.net/index.php?title=PCD_Profile_Implantable_Device_Cardiac_Observation.  http://wiki.ihe.net/index.php?title=Patient_Care_Devices.

3.1

IHE (Integrating the Healthcare Enterprise).

La asociación IHE se creó en 1998 por parte de usuarios y empresas de Estados Unidos para dar respuesta a los crecientes y urgentes problemas de interoperabilidad en el dominio de radiología. Las Sociedades de usuarios RSNA y HIMSS crearon una única plataforma para que los usuarios y vendedores pudieran definir especificaciones sobre Sistemas de Información Sanitarios que permitieran la interoperabilidad entre aplicaciones complejas. El concepto de IHE fue adoptado por Europa y Asia poco después. Las actividades Europeas comenzaron en el año 2000 por el COCIR y el Congreso Europeo de Radiología (ECR) [9]. Integrating the Healthcare Enterprise, que abreviamos como IHE y que podría traducirse al castellano como Integrando las Empresas Sanitarias, es una iniciativa
20

Metodología

de profesionales de la sanidad (incluyendo colegios profesionales de médicos) y empresas proveedoras cuyo objetivo es mejorar la comunicación entre los sistemas de información que se utilizan en la atención al paciente. 3.1.1 Dominios del IHE. IHE ofrece soluciones en dominios clínicos como cardiología, laboratorio y radiología, así como también dominios horizontales como infraestructura de tecnologías de la información y también dominios clínicos mixtos como coordinación de la atención del paciente. Las áreas (dominios) de aplicación están en constante desarrollo en función de las necesidades de los usuarios y son las siguientes.           Anatomía Patológica. Cardiología. Infraestructura TI. Laboratorio. Coordinación de la atención al paciente. Dispositivos de cuidado al paciente. Calidad, Investigación y Salud Publica. Farmacia. Radiología. Oncología.

Siendo nuestro dominio de interés el de “Dispositivos de cuidado al paciente” el que describiremos en este proyecto, para evitar confusiones, a partir de este momento haremos referencia a tal dominio con su nombre en ingles “Personal Care Device (PCD). 3.1.2 Cómo funciona los perfiles del IHE. IHE define unos perfiles de integración en cada dominio (área) que utilizan estándares ya existentes para la integración de sistemas de manera que proporcionen una interoperabilidad efectiva y un flujo de trabajo eficiente [10]. Los perfiles han sido elaborados para tener en cuenta un amplio rango de procesos clínicos e incluyen muchas características opcionales. Para obtener la interoperabilidad, respecto a una tarea clínica específica, IHE crea perfiles basados en los estándares más apropiados (HL7, DICOM, ISO) (Ver figura 3.1).

21

Metodología

Figura 3.1. Proceso de trabajo del IHE para la creación de nuevos perfiles

Los perfiles IHE especifican la información que debe ser intercambiada entre dos sistemas y las acciones que los sistemas receptores deben realizar al recibir la información [9]. Estos perfiles proporcionan un marco basado en estándares para el intercambio de la información. Ellos abordan los temas críticos de interoperabilidad relacionados con acceso a la información sanitaria, definiendo normas en cuestión de seguridad, administración e infraestructura de la información. Cada perfil define los actores, las transacciones y el contenido de la información necesaria para abordar un caso clínico específico. Hemos hablado que el IHE se basa en perfiles de trabajo para poder resolver cualquier problemática de comunicación entre los sistemas de información sanitarios, pero que son realmente estos perfiles, ¿Para qué nos sirven?, ¿ Qué ventajas ofrecen ?. El perfil de integración IHE son documentos que describen a detalle una necesidad clínica de cómo debe solucionarse los problemas de interoperabilidad, definiendo los componentes funcionales, a los que se les llama actores IHE, y especificando con el mayor grado de detalle posible las transacciones que cada actor deberá llevar a cabo, basadas siempre en estándares como el de Digital Imaging and Communication in Medicine (DICOM) y Health Level 7 (HL7). Este flujo de la información se describe en estos perfiles con términos de transacciones. Todas las transacciones entre actores requeridas para completar el flujo de trabajo (tarea clínica) son especificadas claramente. Las especificaciones describen como se van a utilizar partes específicas de los estándares y proporcionan pautas técnicas para la implementación de las aplicaciones. En otras palabras, es una guía, en la cual una vez identificados los principales componentes o sistemas que queremos integrar (actores según el modelo de perfiles del IHE), nos indica las funciones, reglas y los mas importante el tipo de estándar que debe usar cada sistemas para compartir y recibir la información. En la figura 3.2 están explicados los componentes que intervienen en un perfil del IHE. A manera de ejemplo se muestran como actores el sistema gestor de información
22

Metodología

cardiaca de la empresa Biotronik, así como un sistema gestor de información hospitalaria.

Biotronik Home Monitoring
Actor

Información Transacción

Sistema gestor de información hospitalaria
Actor

Figura 3.2. Componentes de un perfil del IHE.

3.2

Dominio IHE-PCD (Patient Care Device).

Entre los dominios existentes del IHE, existe uno que tiene que ver con los dispositivos médicos utilizados en el proceso de diagnóstico, seguimiento, tratamiento o la prevención de enfermedades al paciente, el cual es llamado Patient Care Device (PCD), ofrecido libremente a cualquier institución que quiera alcanzar un interoperabilidad entre dispositivos médicos y sistemas informáticos, haciendo uso de las guías establecidas en dicho dominio. El dominio IHE Patient Care Device (PCD) fue formado en 2005 para hacer frente a la integración de los datos de los dispositivos médicos en la historia clínica electrónica, obteniendo como resultado mejoras significativas en la seguridad del paciente y la calidad de la atención. Este dominio está siendo ampliamente usado, para la integración los dispositivos médicos, como también es usado para la gestión de alarmas que generan los distintos dispositivos médicos. La figura 3.3 muestra la arquitectura y el flujo de datos de este dominio.

23
Figura 3.3. Arquitectura del dominio PCD.

Metodología

Tipos de datos usados en el dominio IHE-PCD:     Datos fisiológicos periódicos (frecuencia cardiaca, presión arterial invasiva, frecuencia respiratoria, etc.) Datos fisiológicos aperiódicos (presión arterial no invasiva, peso del paciente, etc.) Información de las alarmas y alertas de dispositivos médicos. Configuración del dispositivo, así como manipular dichas configuraciones.

3.2.1 Perfiles del dominio IHE-PCD(Patient Care Device) Los perfiles que contiene el dominio IHE Patient Care Device son diseñados para transmitir datos o alertas de diferentes dispositivos médicos de monitorización, por lo cual, el uso de estos perfiles eliminan la necesidad de introducir la información del paciente en el dispositivo, así como la de transcribir la información en la historia clínica del paciente, permitiendo de esta manera que los datos del dispositivo estén inmediatamente disponibles y accesibles en cualquier momento. Estos perfiles describen un escenario real clínico, ya que involucran a un conjunto de actores (sistemas o personas), especificando para cada uno de ellos las transacciones (acciones) que deben usar cada uno de ellos. Como se menciona anteriormente cada dominio contiene diferentes perfiles, así como diferentes estados en los que se encuentra el perfil. La tabla siguiente se menciona los perfiles existentes en este dominio:
Tabla 1.3 Perfiles del dominio Patient Care Device (PCD).

24

Metodología

3.3

Perfil IHE-PCD-IDCO (Implantable Device Cardiac Observation).

3.3.1 Introducción. Actualmente los cardiólogos hacen uso de desfibriladores, terapias de re sincronización y dispositivos de monitoreo cardiaco para el seguimiento continuo de la salud de sus pacientes. Este seguimiento se realiza con equipos propietarios (sistemas de interrogación), comúnmente llamados programadores, que son los encargos de la comunicación con estos dispositivos. Los datos obtenidos de este seguimiento son información sobre el estado y configuraciones de los diferentes tipos de dispositivos, así como datos demográficos de pacientes. Para mejorar los procesos y los servicios clínicos ofrecidos por el área de cardiología, se hace uso de sistemas informáticos de información cardiológica para centralizar y gestionar la información obtenida, de manera que este accesible en cualquier momento. Para solucionar este problema, este perfil define una guía o metodología basada en la transferencia de datos obtenidos desde los sistemas de interrogación o sistemas de información cardiológica, hacia los sistemas gestores de información clínica existentes. En él se define un mecanismo para la creación, transmisión y procesamiento de datos discretos e informes asociados con las medidas realizadas por dispositivos cardiacos implantables. Soporta los casos de uso tanto clínico como remoto. La imagen 3.4 muestra el flujo de datos de este perfil.

Clínico

Remoto

Figura 3.4. Flujo de datos del perfil IHE-PCD-IDCO en situaciones clínico y remoto.

25

Metodología

Los objetivos de este perfil son:   Obtención de la información estandarizada proveniente de un dispositivo cardiaco implantable. La mejora de la eficiencia del flujo de trabajo en las áreas de cardiología y electrofisiología, obteniendo la información centralizada y estructurada del paciente y de los datos de su dispositivo de cardiaco de monitorización.

3.3.2 Actores y transacciones. Anteriormente se explicó a detalle que cada perfil según la metodología del IHE está conformado por actores (sistemas que intercambiaran la información) y transacciones que es de que manera la información será intercambiada (estándares HL7, DICOM, ISO). Ahora bien, teniendo claro este concepto, es necesario hacer mención sobre cuáles son los roles o acciones que cada actor ejerce, por lo cual basándonos en la descripción del marco teórico de este perfil, podemos observar que en la siguiente tabla se identifican los actores y sus roles que en conjunto con otros actores (otros sistemas) hacen uso de transacciones para realizar una acción en particular (Ver figura 3.5). Nótese que cada actor tiene un nombre diferente según el perfil y rol en el que se desenvuelve, por ejemplo para un perfil en el domino de patología el nombre del actor sería diferente de este, al igual que su rol [11].

Figura 3.5. Diagrama de actores y transacciones del perfil IHE-PCD-IDCO.

26

Metodología

La tabla siguiente muestra las funciones principales de estos actores.
Tabla 1.4 Funciones de los actores del perfil IHE-PCD-ICDO.
Nombre del Actor Implantable Device – Cardiac – Reporter (DOR) Función Envía la información obtenida del programador o un sistema de monitorización en formato HL7 de tipo ORU. El mensaje contiene los datos de estado, configuración del dispositivo de monitorización cardiaca.

Implantable Device – Cardiac – Consumer (DOC)

Recibe la información en formato HL7 ORU y ejecuta una acción predeterminada. Estas acciones generalmente son la creación de reportes, integración de información en sistemas de historia clínica personales, creación de estadísticas, etc.

La imagen anterior nos da una idea más clara de cómo se hace la interacción entre los actores, haciendo uso de transacciones para poder efectuar la comunicación, es importante no confundir y entender claramente que aquí el actor Device Observation Reporter (DOR) no es solamente el dispositivo implantable cardiaco que intercambia la información, sino puede ser su sistema gestor de información cardiaca, o su programador, lo importante y para que pueda ser considerado como DOR, es que pueda establecer una comunicación con otros sistema que en este caso sería el DOC, haciendo uso de la transacción PC-09 , que como hemos visto es simplemente el formato en que los datos son enviados (HL7/ORU). Para el caso del actor Device Observation Consumer (DOC) es necesario que este sistema pueda entender la transacción PC-09, ser capaz de procesar los mensajes HL7 de tipo ORU, para después hacer uso de la información como por ejemplo creando un registro de historia clínica electrónica del paciente. 3.3.3 Descripción funcional Según el marco teórico del dominio Patient Care Device PCD, podemos ver que en la sección del perfil IDCO, nos encontramos que se usa la transacción PCD-09 para poder establecer un intercambio de información entre actores, este nombre es solamente con la finalidad de poder diferenciarlos de otras transacciones, ya que es posible que dentro de un perfil especifico se puedan hacer uso de varias transacciones diferentes. Bueno en realidad la transacción PCD-09 es la forma en que comparten los datos los actores, que otras palabras son simplemente los datos del dispositivo cardiaco implantable que ya viene en un formato específico y estructurado, para esta transacción se usa el estándar HL7 para su envió. Para este tipo de mensaje se usa el tipo ORU, que según el estándar HL7 es usado para
27

Metodología

órdenes no solicitadas y mensajes de observación, en secciones más adelante se describen las cabeceras del mensaje, así como los campos necesarios para poder estructurar la información y enviarla. Para la interpretación de los datos provenientes de los dispositivos cardiacos implantables es necesario que el programador o sistema de interrogación realice un mapeo de datos, siguiendo las estructura del estándar IEEE 11073_10103, que definen la estructura en la que los dispositivos médicos intercambian información entre sí o a otros sistemas, más adelante se explica a mas detalle este protocolo. 3.3.4 Estándares. Los estándares usados para el intercambio de información en el perfil IHE-PCDIDCO son HL7 y IEEE 11073_10103. . 3.3.4.1 HL7 V2.5x ORU

Este estándar es usado para definir de qué manera son intercambiados los datos entre los actores correspondientes. HL7 International (Health Level Seven) es una “Organización de Desarrollo de Estándares” para el ámbito de la salud. Fundada en 1987 sin fines de lucro, opera a nivel internacional y su misión es proveer estándares globales para los dominios: clínico, asistencial, administrativo y logístico, con el fin de lograr una interoperabilidad real entre los distintos sistemas de información en el área de la salud [12]. 3.3.4.1.1 Componentes de un Mensaje HL7

Cada mensaje HL7 consiste de uno o más segmentos, separados por el carácter “\r” (0D en hexadecimal). Estos segmentos pueden tener uno o varios campos que se separan uno del otro usando el carácter de pipa “|”. Los campos también pueden contener otros campos (sub-campos) que normalmente se separan con el carácter “^”. Ejemplo de un mensaje de HL7:
MSH|^~\&|LCS|LCA|LIS|TEST9999|199807311532||ORU^R01|3629|P|2.2 PID|2|2161348462|20809880170|1614614|20809880170^TESTPAT||19760924|M|||^^^^ OBR|1|8642753100012^LIS|20809880170^LCS|008342^UPPER RESPIRATORY

Cada segmento contiene información de una categoría específica, como por ejemplo, datos personales del paciente, o datos relacionados con la consulta médica realizada al paciente. Los nombres de los segmentos son especificados en el primer campo del

28

Metodología

segmento, como vemos en el ejemplo anterior que contiene los segmentos MSH, PID y OBR. Existen alrededor de 120 tipos de segmentos son usados en los mensajes HL7 [13]. 3.3.4.1.2 Caracteres delimitadores en HL7

La siguiente lista muestra los caracteres delimitadores usados en HL7.

Carácter
0x0D | ^ & ~ \

Función
Indica el fin de cada segmento Delimitador de campo Delimitador de sub-campo Delimitador de sub-sub-campo. Separa campos repetidos Carácter de escape

3.3.5 Proceso de trabajo del IHE-PCD-IDCO.

Figura 3.6. Flujo de información en un escenario IDCO.

29

Metodología

La figura 3.6 muestra el flujo de información requerido en un escenario común de un chequeo rutinario de un dispositivo de monitoreo cardiaco, ya sea remoto o en clínica, nótese que el perfil IHE-PCD-IDCO simplemente establece la metodología de cómo estos datos deben ser intercambiados entre las etapas 5 y 6, pues las secciones 1,2 y 3 son datos propietarios en los cuales nosotros no podemos tener acceso a ellos. Este proyecto de investigación ofrece soluciones a las aéreas 4, 5, 6, 7. La descripción de las etapas del proceso se describe a continuación: 1. Send Interrogation – El dispositivo envía la información hacia el programador o sistema de interrogación en un estándar propio de la compañía manufacturera. 2. Send Interrogation – El sistema de interrogación o programador envía esta información (estándar propio de la empresa) hacia el actor Implantable Device Cardiac Reporter. 3. Validate and Review – Esta información es validad por el actor Implantable Device Cardiac Reporter, aquí puede incluirse una revisión y análisis rápido de datos por parte del médico. 4. Translate Information – El actor Implantable Device Cardiac Reporter traslada, mapea o transforma la información en el mensaje HL7 ORU correspondiente según el perfil IHE-PCD-IDCO. 5. Send Observation – El actor Implantable Device Cardiac Reporter envía la información hacia el actor Implantable Device Cardiac Consumer mediante la transacción PCD-09 (mesaje HL7). 6. Receive Observation – El actor Implantable Device Cardiac Consumer recibe esta información. 7. Process Observation – El actor Implantable Device Cardiac Consumer procesa esta información para analizarla, almacenarla o integrarla a un sistema gestor de historia clínica. 3.3.5.1 IEEE 11073_10103. Este estándar es un conjunto de terminologías para el intercambio de información de sistemas médicos. Es creado por la asociación IEEE y es el encargado de definir las normas de qué manera deben ser intercambiados los datos de los dispositivos cardiacos implantables. Es necesario e importante que en la etapa cuatro, la estructura de datos de salida, siga el protocolo de intercambio de información IEEE 11073_10103 para poder hacer el mapeo correspondiente a un mensaje HL7/ORU e implementar correctamente este
30

Metodología

perfil, la ausencia de este formato en esta etapa causaría que este perfil no pudiera ser realizado de ninguna manera. Para mencionar un ejemplo los datos que nuestro actor Device Observation Reporter, va a tener que procesar para generar el mensaje de salida en formato HL7/ORU sería el siguiente.

Aquí se observa un fragmento del archivo de entrada que sigue el estándar IEEE 11073_10103 en formato XML. En la sección de anexos (Archivo de entrada usado como ejemplo con la Nomenclatura IEEE 11073 MDC_IDC ) se encuentra el archivo completo en este formato que fue usado como archivo de ejemplo para este proyecto. 3.3.6 Consideraciones de Identificación del paciente. Dependiendo de las regulaciones locales de cada proveedor de dispositivos cardiacos implantables, se puede estar obligado a mantener un registro que identifica a un paciente con único dispositivo implantado. Generalmente la información de identificación personal del paciente, no suele estar almacenada internamente en estos dispositivos, siendo solo accesibles desde los programadores o sistemas gestores de información clínica. Para poder lograr que la información de un paciente sea la correcta, es necesario asociar un identificador entre el registro del paciente y el dispositivo, este identificador es universal y no se puede repetir, en la normativa que establece este perfil nos indica el id de la empresa manufacturera, como el número de serie y modelo serán estos identificadores, por ejemplo: Manufacturer: BSC (Boston Scientific), MODEL: 1234 SERIAL:ERYU y un caso real de aplicación se ilustra en la imagen siguiente.

31

Metodología

Paciente

Sistema gestor de información cardiológica

Registro electrónico del paciente
Id: BSC/1234/ ERYU Nombre: Alvaro Cortes Mánica Teléfono: 622496545 SS: 7878899999

Id: BSC/1234/ ERYU

….
Figura 3.7. Obtención del Identificador del Paciente.

3.3.7 Transacción PCD-09. Esta transacción como hemos explicado en secciones anteriores, es la que contendrán el mensaje con la estructura HL7/ORU v2.5, esta información deberá estar formada a partir de la nomenclatura IEEE 11073-10103 IDC. El funcionamiento es el siguiente (Ver figura 3.8): El actor Device Observation Reporter inicia una comunicación de tipo HL7/ORU hacia el actor Device Observation Consumer. Esta comunicación es definida en el perfil como la transacción PCD-09 y solamente va hacia un sentido.

PCD-09
Device Observation Reporter

HL7 ORU Observación

Device Observation Consumer

Figura 3.8. Funcionamiento de la transacción PCD- 09.

3.3.7.1

Mensaje HL7/ORU.

A continuación se describe los componentes principales de los que está compuesto el mensaje HL7/ORU (Ver tabla 1.5). Para su mejor compresión se menciona un ejemplo del valor de los campos de cada segmento.

32

Metodología

Tabla 1.5 Estructura del mensaje HL7/ORU.

De estos segmentos los que son obligatorios de usar, son los siguientes: MSH, PID y OBR, siendo los demás segmentos opcionales de su implementación.

3.3.7.1.1

Segmento MSH – Cabecera del Mensaje.

Cabecera del mensaje, que indica, entre otras cosas, el tipo de mensaje, define los limitadores e identifica el evento disparador.

33

Metodología

Tabla 1.6 Estructura del segmento MSH.

MSH-1 Field separator. Es usado para poder separar dentro del mensaje HL7 los campos existentes, el dominio IHE PCD requiere que dicho separador sea el signo “|”. MSH-2 Encoding Character. Este campo contiene los caracteres usados en el mensaje de la siguiente manera, el primer carácter es el usado para separar los atributos de cada campo, el segundo es para indicar repetición, el tercero es el carácter de escape y el último es el separador de subcomponente que indica que el atributo se subdivide en más campos. El dominio IHE PCD especifica que se usen los siguientes caracteres ^~\& que son los que recomienda el estándar HL7. MSH-3 Sending Application (HD). Este campo nos indica el nombre del software o sistema que envía el mensaje, en el contexto del IHE sería el nombre del actor Device Cardiac Reporter (DOR). Ejemplo: BioHMSC.

34

Metodología

MSH-4 Sending Facility . Se especifica el nombre de la organización responsable del actor Device Cardiac Reporter (DOR) que envía la información, o también el departamento que opera el sistema (DOR). Ejemplo: Biotronik. MSH-5 Receiving Application. Estos componentes son los mismos usados que en el campo MSH-3, solo que en vez del nombre de la aplicación que envía el mensaje, se debe rellenar con el nombre de la aplicación a quien va dirigido el mensaje. En el contexto del IHE este sería el nombre de la aplicación del actor Device Cardiac Consumer (DOC). Este campo es opcional pero puede ser usado para filtrar mensajes y que solo sean leídos por una aplicación en particular. Ejemplo: Cardiosoft. MSH-6 Receiving Facility. Especifica el nombre de la organización responsable del sistema que recibe el mensaje o también el departamento que opera el sistema (DOC). Ejemplo: Hospital La Fe. MSH-7 Date/Time of Message. Es la fecha de cuando se genero el mensaje indicando la zona horaria, siguiendo el formato siguiente. Fecha: YYYY[MM[DD[HH[MM[SS]]]]]+/-ZZZZ. Ejemplo: 201203111025+03000. MSH-9 Message Type. Este campo indica el tipo de mensaje que se está enviando, al igual que nombre del evento disparador. Ejemplo: ORU^R01. MSH-10 Message Control Id. Es el identificador de cada mensaje, por lo cual el sistema que envía el mensaje (actor DOR) debe de generarlo, a su vez el actor DOC debe de regresar este ID al DOR en el segmento de MSA del mensaje de confirmación (mensaje ACK). Este mensaje puede ser hecho combinando el nombre del sistema DOR, o bien por un numero aleatorio, procurando que se único en el sistema. Ejemplo: 8C6F5C4F3800B1CA942363017AD36F68. MSH-11 Processing ID. Indica cómo será procesado el mensaje y debe ser rellanado con los valores siguientes. D – Debugging. P – Production. T – Training.
35

Metodología

Ejemplo: D. 3.3.7.1.2 Segmento PID – Identificación del Paciente.

Este segmento es usado por las aplicaciones para poder enviar información del paciente, como datos demográficos que están contenidos en el mensaje final de salida.
Tabla 1.7 Estructura del segmento PID.

PID-3 Patient Identifier List. Este campo contiene en único id para cada paciente y es asignado por el sistema DOR, este id es generado con los valores especificados en la tabla HL7 Table 023 del estándar (Ver tabla 1.8). Siempre se pone como primer valor el modelo o numero de serie del dispositivo implantable, y en el tipo de identificador (sub-campo cuatro) el valor U. Para el componente Assigning Authority (sub-campo cinco) el valor será un nombre creado por el actor DOR, o en su caso un nombre propio de la organización codificado con las nomenclaturas MDC_IDC_PG_MFG que especifica el nombre de la empresa manufacturera.

36

Metodología

Tabla 1.8 HL7 Table 023.

Ejemplo: MODEL:LUMAX 300 VR-T/SERIAL:110011^^^BIO^U

PID-5 Patient Name. Este campo contiene el nombre del paciente, apellido y sufijos del paciente. Ejemplo: CORTES^ALVARO. PID-7 Date/Time of Birth. Es la fecha de cuando se genero el mensaje indicando la zona horaria, siguiendo el formato siguiente. Fecha: YYYY[MM[DD[HH[MM[SS]]]]]+/-ZZZZ. Ejemplo: 201203111025+03000. PID-8 Administrative Sex. Contiene el sexo del paciente y debe tener los valores de la tabla 0001 del estándar HL7 (Ver tabla 1.9).
Tabla 1.9 HL7 Table 0001.

PID-11 Patient Address. Contiene la dirección del paciente. Ejemplo: Pintordevilar4^^Valencia^^^España.

37

Metodología

PID-12 Version Id. Es la versión del mensaje HL7 que se envía. Ejemplo: 2.5 3.3.7.1.3 Segmento PV1– Visita del Paciente (Opcional).

Es utilizado para comunicar la información específica de la visita del paciente y puede ser omitido en la estructura del mensaje final.
Tabla 1.10 Estructura del segmento PV1.

PV1-2 Patient Class. Es usado para categorizar al paciente y sus valores dependen la tabla HL7 0004 del estándar (Ver Tabla 1.11). Ejemplo: E
Tabla 1.11 HL7 Table 0004.

PV1-7 Attending Doctor. Especifica el identificador único del doctor que ha hecho la consulta, este id solo es válido en el actor DOR. PV1-19 Visit Number. Identificador único de la visita creado EB7A5C4F4A0098B2BCE3063BE6FDBD06. por el actor DOR. Ejemplo:

38

Metodología

3.3.7.1.4

Segmento OBR– Solicitud de Observación.

Contiene el detalle específico de los datos obtenidos de los dispositivos cardiacos implantables.
Tabla 1.12 Estructura del segmento OBR.

OBR-2 Placer Order Number. Es el id de la orden emitida. Ejemplo: 1. OBR-3 Filler Order Number. Es un identificador único para identificar la sesión generada por el actor DOR. Ejemplo: 123455. OBR-4.1-2 Universal Service ID. Indica en qué situación se ha realizado la sesión. Estos valores deben de ser tomados desde el protocolo 11073_10103 del enumerador MDC_IDC_SESS_TYPE. Ejemplo: Remote. OBR-7 Observation Date/Time. Indica la fecha y la hora en la que fue hecha la sesión. Ejemplo: 20040328134623.1234+0300. OBR-8 Observation End Date/Time. Indica la fecha y la hora en la que se termino la sesión. Ejemplo: 20040328134623.1234+0300.

39

Metodología

OBR-25 Result Status. Indica el estado de los datos enviados, debe contener los valores de la siguiente tabla. Ejemplo: R.
Tabla 1.13 Estado del mensaje.

3.3.7.1.5

Segmento OBX– Resultado de las Observaciones.

En este segmento es usado para proporcionar la información proveniente desde el dispositivo cardiaco implantable. Un mensaje HL7 puede tener varios segmentos OBR, en este caso para diferenciar cada uno de ellas se debe de poner un identificador diferente en cada campo Set-ID de cada uno de ellos. Su estructura se muestra en la tabla 1.14.
Tabla 1.14 Estructura del segmento OBX.

40

Metodología

OBX-1 Set ID. El identificador de la secuencia. Ejemplo: 1.OBX-2 Value Type. Hace referencia al tipo de dato que se ha medido. Según la normativa del perfil IHEPCD-IDCO, debe de ser codificado del tipo de datos del estándar e IEEE 11073 MDC_IDC al tipo de datos HL7. Ejemplo: ST.
Tabla 1.15 HL7 Table 0001.

OBX-3.1 Observation Identifier. Este identificador es usado para poder identificar los valores de datos extraídos de los dispositivos médicos implantables. Se debe ajustar a la nomenclatura 11073_10103. En la sección de anexos (Nomenclatura IEEE 11073 MDC_IDC) se muestra la lista completa de la nomenclatura de este estándar. Ejemplo: 738050. OBX-3.2 . Es codificado con el nombre de ID según la nomenclatura 11073_10103. Ejemplo: MDC_IDC_STAT_EPISODE_TOTAL_COUNT_DTM_END. OBX-3.3 Observation Identifier. Siempre se usara el término “MDC”, que indica el tipo de observación realizada. OBX-3.4-6 Alternate Identifier. Usado para poner otro tipo de identificador como por ejemplo códigos LOINC. OBX-5 Observation Value. Valor actual de la observación. Ejemplo: 8.5. OBX-6 Unit. La unidad que deberá seguir la nomenclatura MDC_IDC (basado en la nomenclatura UCUM). Se forma primero poniendo un valor MDC seguido de un valor UCUM. Ejemplo: s^UCUM.

41

Metodología

OBX-11 Observation Result Status. Este valor deberá ser llenado siguiendo la tabla HL7 0085. Ejemplo: F.
Tabla 1.16 HL7 Table 0085.

OBX-14 Date/Time of the Observation. La fecha de la observación, será requerida solamente cuando sea diferente en la fecha de inicio del segmento anterior OBR. OBX-18 Equipment Instance Identifier. El identificador del software que realizo la observación. Ejemplo: Biotronik. 3.3.7.1.6 Segemento NTE– Comentarios y Notas (Opcional).

En esta sección es usada para agregar comentarios, que no son parte de las observaciones finales.
Tabla 1.17 Estructura del segmento NTE.

NTE-1 Set ID. Es el identificador de la nota por si hubiera más de una registrada.
42

Metodología

NTE-3 Comment. Es el contenido del comentario.

3.3.7.2

Mensaje de Autentificación (ACK).

Una parte importante del estándar HL7 es el mensaje de respuesta. Cada vez que una aplicación acepta una comunicación para procesar un mensaje en formato HL7, es obligada a dar una respuesta (mensaje ACKnowledgment) para indicar que el mensaje ha sido recibido. Los componentes del mensaje ACKnowledgment (ACK) son:   Una cabecera MSH, que contiene información sobre la aplicación que envía los datos, así como el identificador único del mensaje. Una cabecera MSA, que indica si el mensaje ha sido aceptado o rechazado.

La figura siguiente muestra un mensaje ACK con los componentes señalados.

Figura 3.9 Estructura del mensaje ACK.

Para identificar si el mensaje ha sido aceptado o en su caso ha tenido un error, el primer campo de la cabecera MSA debe de tomar uno de los valores de la siguiente tabla [7].

43

Metodología

Tabla 1.18 Valores posibles del primer campo de la cabecera MSA.

Valor
AA

Significado
El mensaje fue recibido sin ningún error.

AE

Error de la aplicación: hay un problema en el procesamiento del mensaje. La aplicación remitente debe de arreglar el problema antes de intentar enviar de nuevo el mensaje

AR

Solicitud de rechazo: existe un problema con los campos 9, 11 o 12 del segmente MSH del mensaje enviado, o hay un problema con la aplicación receptora que no está relacionada con el mensaje o su estructura.

3.3.7.3

LLP- Lower Layer Protocol.

El modo común para enviar los mensajes HL7 es el estándar llamado “Lower Layer Protocol” (LLP), aunque existen sistemas que envían su información usando el protocolo FTP, SOAP and SMTP. Este tipo de transmisión usa el protocolo de comunicación TCP/IP, para el envió de paquetes que contienen la información con el mensaje HL7, se basa en que la información es encapsulada indicando el principio y final de los datos por medio de caracteres especiales, por supuesto este estándar solo es usado para compartir datos de redes locales, pues carece de un método de encriptación. La estructura típica de un mensaje HL7 enviado con el protocolo TCP/IP, usando el estándar LLP se muestra a continuación en la tabla 1.19 [6].

44

Metodología

Tabla 1.19 Estructura de un mensaje HL7 con el estándar LLP. Cabecera Hl7 mensaje Trailer Retorno de carro
Caracter (0x0D)

Carácter vertical tab (0x0B)

MSH|^~\&||.|||199908180016||ADT^A04|ADT.1.1698593|P|2.5 PID|1||000395122||LEVERKUHN^ADRIAN^C^^^||19880517180606|M|

Separador de campo (0x1C)

45

Soluciones

4. SOLUCIONES PLANTEADAS.
Esta sección se exponen las soluciones para resolver la problemática planteada, se describe un caso real de un proceso de seguimiento de pacientes con dispositivos cardiacos implantados, esto con la finalidad de tener punto de partida específico, permitiéndonos identificar los componentes principales que estarían involucrados en el diseño del proyecto. Este caso de uso está basado siguiendo el flujo de trabajo que actualmente se realiza en el seguimiento a pacientes con dispositivos cardiacos tratando de ser lo más realista posible, esto permitió adecuar el proyecto usando las herramientas tecnológicas que serían necesarias para el desarrollo de este proyecto. 4.1 CASOS DE USO. Supongamos el paciente Alex Cortes, que presenta problemas del corazón y su médico le ha indicado que es necesario implantarle un marcapasos para mejorar su estado de salud. De este problema se plantean dos escenarios posibles. 4.1.1 EN EL HOSPITAL. Alex presentará un seguimiento rutinario durante los siguientes 7-10 días, después del implante del marcapasos y de 3 a 6 meses dependiendo la terapia que se le ha asignado. Su cardiólogo usa el programador para configurar y extraer datos (estados, eventos) del marcapasos. El cardiólogo revisa y analiza los datos del marcapasos, y los envía a un sistema traductor que se encargara de traducir los datos propios del fabricante al estándar HL7, para que posteriormente sean enviados a un sistema de información de gestión hospitalaria 4.1.2 REMOTO. Alex en este caso tendrá en su casa un sistema de interrogación que lo mantendrá monitorizado todo el día, obteniendo el estado del marcapasos y enviándolo a un sistema traductor para convertir estos datos de un formato propietario en un mensaje HL7 para su posterior integración en un sistema de gestión de información hospitalaria.

46

Soluciones

La figura siguiente muestra el flujo de trabajo

Figura 4.1. Flujo de datos en situaciones clínico y remoto

Podemos observar en la figura anterior que de qué manera fluye la información en los escenarios de hospital y remoto. Para el caso del hospital el programador extrae la información del dispositivo cardiaco y lo envía a un sistema gestor de información cardiaca que puede ser cualquiera que hemos visto en la sección de introducción. Este sistema gestor almacena la información para después si se le solicita, la puede enviar al sistema gestor de historia clínica para incorporarla al historial del paciente. Para el caso Remoto la información es enviada a un servidor central, propio de la empresa ( Servidor Web Vendor), para después si es necesario puede ser enviada a un sistema gestor de información como sucede en el caso del Hospital o finalmente directamente al sistema gestor de historia clínica. Está claro que muchas veces los datos obtenidos de estos dispositivos se quedan almacenados en el programador , en el sistema gestor de información cardiaca o en su caso el servidor central de la empresa manufacturera del dispositivo ( Servidor web vendor), sin poder ser compartidos, permitiendo de estar manera no llegar a integrar los datos en la historia clínica del paciente. Este problema puede ser resuelto haciendo uso de herramientas integradoras que nos permiten generar, procesar, gestionar y estandarizar la información de manera que pueda ser compatible y entendible por otros sistemas informáticos. Es aquí en esta sección donde los perfiles del IHE entran en juego y ofrecen una solución a este problema, siendo esta

47

Soluciones

parte del flujo de comunicación la base central del desarrollo del proyecto, esta sección está marcada con un rectángulo azul en la figura 4.1,

4.2 Identificación de actores.
Lo primero que se tuvo que investigar, era saber de qué manera los programadores e interrogadores, extraían y compartían la información. Se había pensado en primera opción hacer un módulo que se comunicara directamente con el marcapasos para extraer dicha información y después procesar lo datos y enviarlos en formato HL7 como lo indicaba la metodología del perfil. El gran problema que se tuvo aquí fue que después de investigar los diferentes modelos de programadores, e inclusive preguntar a profesionales que se dedican a implantar este tipos de dispositivos, nos encontramos con el problema que estos datos son de estándares propios fabricados por las compañías manufactureras de estos dispositivos, por lo cual fue imposible llevar a cabo esta primera idea pues trabajar con estos estándares, es demasiado complicado, conlleva mucho tiempo de desarrollo, y solo se podría hacer una sola aplicación para un marcapasos en cuestión, dejando el proyecto sin el objetivo especifico, el cual era la de procesar la mayoría información de datos de marcas de dispositivos cardiacos implantables, además de que es necesario conocer estos estándares propios, los cuales son muy difíciles de obtener pues las compañías no lo ofrecen para evitar plagios industriales. Además de esta problemática, tenemos que mencionar que el programador no entraría como un actor, pues el perfil IHE-PCD-IDCO (Ver figura 4.1) especifica que para ser considerado como actor, es necesario que la información que comparta sea entregada en formato el estándar HL7. Así que esta idea fue descartada de inmediato por qué no seguía la metodología del perfil, dejando al programador fuera del proceso de diseño. Una vez teniendo identificada la sección en la cual se necesitaba implementar el perfil IHE-PCD-IDCO, era necesario distinguir los actores que estarían involucrados, en otras palabras era necesario identificar los sistemas informáticos que iban a intercambiar la información, como vemos en el proceso de trabajo del caso de uso estos sistemas serian: el servidor Web vendor, el sistema gestor de información cardiaca, y el sistema gestor de historia clínica. En la metodología del IHE, nos plantean dos posibles actores uno que se encargaría de enviar la información procesada en mensaje HL7 que se llama Device Cardiac Reporter (DOR), y el otro llamado Device Cardiac Consumer (DOC) que es el encargado de recibir la información procesarla e integrarla al historial clínico del paciente, que se encuentra en el sistema gestor de información clínica En este caso la identificación de los actores se presenta en la tabla siguiente.

48

Soluciones

Tabla 1.20 Descripciones de autores del proyecto.
Nombre del sistema Nombre Actor según el perfil IHE-PCD-IDCO Implantable Device – Cardiac – Reporter (DOR) Servidor web vendor. Sistema gestor de información Función

Envía la información obtenida del programador o un sistema de monitorización en formato HL7 de tipo ORU. El mensaje contiene los datos de estado, configuración del dispositivo de monitorización cardiaca. Recibe la información en formato HL7 ORU y ejecuta una acción predeterminada. Esta acciones generalmente son la creación de reportes, integración de información en sistemas de historia clínica personales, creación de estadísticas, etc.

Implantable Device – Cardiac – Consumer (DOC) Sistema gestor de historia clínica

Se muestra a continuación el diagrama de actores definido en el perfil IHE-PCDIDCO, con los sistemas participantes en el proyecto. Servidor web Vendor Sistema gestor de información

PCD-09

Sistema gestor de historia clínica

DOC

DOR
Nótese que la palabra DOR se entiende por el actor Implantable Device Cardiac Reporter, en caso contrario la palabra DOC significa Implantable Device Cardiac Consumer (DOC), a partir de ahora nos referiremos a estos actores con estas abreviaturas, pues es mucho más fácil su identificación y entendimiento. La flecha negra indica el flujo de datos en el estándar HL7/ORU, la cual es llamada transacción PCD-09 según este perfil.

49

Soluciones

4.3 Diseño del actor DOR(Device Cardiac Reporter)
Como vimos en la sección anterior, aquí intervienen dos tipos de sistemas diferentes, cada uno tiene características y procesamiento de datos distintos. La problemática hasta este punto seguía siendo la misma que el caso del los programadores y sistemas de interrogación, no se sabía en qué estándar compartían la información, pues estos sistemas cuentan con algoritmos capaces de decodificar estos estándares propios, pues son hechos por la misma casa comercial de marcapasos. Analizando más en detalle estos tipos de sistemas, pudimos encontrar que los sistemas gestores de información cardiaca y los sistemas Web vendor ( pueden verse su explicación en la sección de introducción), entre sus características principales, además de recibir los datos con estándares propios de los programadores, procesar la información, tienen la opción de generar una salida de datos con formato XML siguiendo la nomenclatura IEEE 11073 - 10103 MDC-IDC, la cual puede ser vista en la sección de anexos también. EL siguiente paso fue obtener un archivo de ejemplo con este formato generado por estos sistemas. Como no pudimos tener acceso en formal real a estos sistemas, debido a que solamente los médicos autorizados tienes permisos, tuvimos que investigar en las páginas Web de las compañías desarrolladoras de es este software, si existía un archivo de ejemplo, disponible. La empresa Biotronik en su software sistema gestor de información cardiaca Home Monitoring, ofrece archivos de ejemplos para el desarrollo de software de tercera partes que deseen, implementar una interfaz de comunicación con otro sistema de información médica. Esto sin duda es de gran ayuda ya que permitió contar con una información codificada en un estándar internacional (IEEE 11073 - 10103 MDC-IDC), permitiendo desde este punto implementar un sistema que sea capaz de traducir esta información al estándar HL7. Era necesario desarrollar una interfaz de conexión que funcionaría como un actor DOR, además de que cumpliera su función principal, la cual era de estandarizar la información a formato HL7/ORU, para su envió al actor DOC, para eso era necesario de un adaptador especial que permitiera la comunicación, de estos datos entre actores. La solución más factible fue el uso de plataformas integradores ya existentes que con algunas modificaciones se podían alcanzar los objetivos deseados. Para resolver la problemática planteada fue necesario investigar sobre los diferentes tipos de integradores existentes en el mercado, basándonos principalmente en las siguientes características:  Código abierto: Uno de los objetivos principales era que la implementación de este perfil fuera lo más económica posible, por lo cual se buscaron alternativas de código abierto, para evitar el pago de licencias.

50

Soluciones

Mantenimiento: Que el sistema integrador nos permitiera realizar la integración de manera eficaz, sencilla y si necesidad de tener que optar por código duro, ya que esto provocaría una tarea complicada de mantenimiento. Manejo y configuración: Se requería que se tuviera un fácil manejo, configuración, y sobre todo que contara con todas las herramientas necesarias para el desarrollo del proyecto.

Lo interesante de estos sistemas integradores es que te dan las herramientas necesarias para que las aplicaciones de sistemas informáticos intercambien información de manera fácil. Otro punto a considerar es que con un mismo sistema integrador nos permitió resolver el problema de los actores, que dentro de una misma plataforma tengamos los dos actores involucrados, cumpliendo sus funciones específicas, todo esto mediante algoritmos de programación, codificados en lenguajes específicos de cada sistema integrador. A demás evitamos usar varios sistemas permitiendo un mejor mantenimiento del mismo. A continuación se detallan las plataformas integradoras que se probaron y se usaron, siendo la de la empresa Interfaceware, la que mejor se adapto a las necesidades del proyecto.

4.3.1 Mirth.
Mirth es herramienta de integración de código abierto desarrollada en JAVA, independiente de la plataforma, orientado a la transmisión de mensajes HL7. La transmisión se realiza por medio de canales definidos mediante una interfaz gráfica. Estos canales son: conectores de entrada y salida, filtros y transformadores .Los conectores actualmente soportados son: LLP, base de datos, JMS, Web Services SOAP, archivos, FTP, SFTP. Mediante la interfaz gráfica es posible seleccionar que filtros y transformaciones se le aplican al mensaje entrante antes de enviarlo a la salida. También es posible definir nuevos filtros mediante scripts, o incluso código Java. A su vez, es posible acceder el contenido del mensaje si se define una plantilla determinada para el mismo. Esto puede ser de mucha utilidad si se desean filtrar, por ejemplo, mensajes HL7, según algún atributo específico. Es posible definir transformadores personalizados, también a través de la interfaz gráfica. Mirth ofrece la posibilidad de crear no solo canales simples (un conector de entrada, y uno de salida), si no canales con múltiples conectores de salida, de forma de realizar un broadcast de la información recibida, o un ruteo de la misma. El broadcast se realiza enviando el mensaje luego de filtrado y transformado a varios conectores de salida. Es posible “rutear” el mensaje a distintas aplicaciones, definiendo para un mismo conector de entrada, un conjunto de conectores de salida cada uno con sus filtros y transformadores. También es posible lograr enrutamientos
51

Soluciones

y transformaciones más complejas, uniendo conectores internos al Mirth, es decir, definiendo un conector de salida que envíe el mensaje a uno de los conectores de entrada definidos [14].

Figura 4.2. Arquitectura de Mirth.

Esta plataforma de integración resultó ser bastante interesante, permitiéndonos crear un canal de comunicación, y mediante la realización de un algoritmo de codificación hecho en Java y Phyton, para generar mensajes HL7 de tipo ORU. Con las características de este sistema solo era posible usar archivos XML de entrada, pero con nomenclatura HL7, y no tenía la opción de importar archivos con otro tipo de formato, como en este caso XML con la nomenclatura IEEE 11073 10103 - MDC-IDC, que es nuestro archivo de entrada, al menos en esta versión que se utilizó. Por lo cual este sistema presentaba una gran problemática para ser considerado como la plataforma integradora a usar en este proyecto. Está de más decir que esta solución no fue la que se escogió para la implementación del proyecto por no presentar las características deseadas. Si se requiere más información se pude visitar su sitio web en la siguiente dirección:
 http://www.mirthcorp.com/

52

Soluciones

4.3.2 Iguana.
Iguana es otra plataforma de integración pero esta es de pago y orientado a web, desarrollado por la empresa canadiense Interfaceware, que permite interconectar varias aplicaciones informáticas en el ámbito sanitario de manera rápida y segura. La siguiente lista muestra las características más importantes de este sistema integrador.      Creación sencilla de tipos de mensajes y documentos: mensajería HL7, documentos HL7-CDA, X12. Ofrece herramientas personalizadas para verificar el funcionamiento de las interfaces creadas. Monitorización y mantenimiento efectivo desde las interfaces creadas, mediante un dashboard basada en tecnología Web (Ver figura 4.3). Realiza interfaces sencillas sin importar el sistema operativo, ni el tipo de base de datos utilizadas. Envió de alertas mediante notificaciones vía email, SMS permitiendo corregir los problemas originados de manera inmediata.

Figura 4.3. Dashboard de Iguana.

Igual que el sistema Mirth funciona por medio de la creación de canales de entrada y salida, por donde fluye la información. La idea es sencilla, la información entra por un canal de entrada determinado, se realiza el procesamiento, mapeo y generación del mensaje, y después es enviado a un canal de salida. Dependiendo si los canales son configurados como entrada o salida, estos tendrán una manera diferente de obtener la información. Iguana tiene las siguientes opciones para sus canales: Para canales configurados como entrada los datos se pueden obtener desde las siguientes opciones:   Protocolo LLP (Ver sección de metodología para su explicación). Base de Datos.
53

Soluciones

   

Archivos locales o un servidor ftp. Protocolo HTTPS. Desde un canal existente. Traductor.

Para canales configurados como salida los datos pueden fluir hacia las siguientes opciones:       Traductor. Base de datos. Cliente LLP. Archivo local. Protocolo HTTPS. Hacia otro canal existente.

La opción de traductores es una característica interesante ya que mediante algoritmos desarrollados con el lenguaje en LUA, son los encargados de traducir la información entrante a una salida predetermina con un formato establecido, que en nuestro caso sería el estándar HL7. Iguana tiene un propio entorno de trabajo para la creación traductores, es muy sencillo, intuitivo además que nos permite trabajar con archivos XML de entrada, que era justamente lo que se estaba buscando.

Figura 4.4. Entorno de desarrollo de Iguana para la creación de traductores.

54

Soluciones

Si se requiere más información se pude visitar su sitio web en la siguiente dirección: 
http://www.interfaceware.com/iguana.html.

Este integrador fue el que más se apego a los características que buscamos en el proyecto, así que fue el elegido para realizarlo. La etapa siguiente fue la de crear los canales de entrada que podría entenderse de una manera como el actor DOR, encargado de recibir la información en formato XML IEEE 11073 - 10103 - MDC-IDC. 4.3.2.1 Diseño de canales de entrada.

Para la creación de nuestro actor DOR, fue necesario crear un canal, en la plataforma Iguana, a manera de identificación este canal fue llamado file_to_channel debido a que se crearon dos canales uno para el actor DOR y otro para el actor DOC. 4.3.2.1.1 Datos de entrada del canal.

Archivos locales o un servidor ftp: Se uso esta opción pues nuestro archivo de entrada se encontraba almacenado en el disco del ordenador donde se ejecutaba el sistema integrador. Aunque era posible obtenerlo desde una dirección de ftp, por falta de tiempo esta última opción no se implemento. La imagen de abajo muestra la configuración del mensaje en la plataforma Iguana.

F i g u r a 1

Figura 4.5. Configuración de datos de entrada del canal.

4.3.2.1.2

Datos de Salida del canal.

Otro canal existente: Se utilizó esta configuración porque era fácil enviar el mensaje mapeado en HL7 hacia otro canal establecido anteriormente, siendo este canal
55

Soluciones

nuestro actor DOC. La imagen siguiente muestra la configuración realizada en los datos de salida. Nótese el nombre de Channel_to_Db que es el canal que hizo la función de nuestro actor DOC.

Figura 4.6. Configuración de datos de salida del canal.

Ya se había diseñado un canal por el cual iba a fluir la información de entrada, fue necesaria hacer la creación de un traductor que permitiera codificar el mensaje de entrada a formato HL7/ORU, para resolver este problema, se tuvo que crear un algoritmo especifico codificado en lenguaje LUA, el cual se encargaría de generar la salida en formato HL7/ORU. La figura 4.7 muestra la imagen una parte del entorno de trabajo para la creación de traductores.

Figura 4.7. Entorno integrado de trabajo para la generación de traductores.

La sección de anexos (Algoritmo LUA creado para el transformador del sistema integrador IGUANA) contiene el código realizado en el lenguaje LUA para la transformación del mensaje de salida.

56

Soluciones

4.3.2.1.3

Identificación del Paciente.

Según el perfil IHE-PCD-IDCO, el actor DOR debería identificar al paciente por medio del modelo y numero de serie del dispositivo cardiaco implantable, este valor estaría relacionado con los datos demográficos del paciente. Sabemos que en casos reales estos datos son gestionados por diferentes tipos de base de datos. Para simular esta situación tratando hacerlo lo más real posible, se tuvo que aprender a usar el gestor de base de datos Mysql, el cual es de licencia libre. El objetivo fue diseñar una base de datos que contendría una tabla con los datos demográficos de un paciente, y otra con el modelo y numero de serie del dispositivo. Las tablas generadas para la identificación del paciente con un dispositivo cardiaco fue el siguiente.

Figura 4.8. Imagen de las tabla id_marca_patient_tbl

Figura 4.9. Imagen de las tabla patient_tbl

De esta manera teníamos relacionada la información del paciente (Id_patient) con el id del dispositivo cardiaco (Idmarcapasos), permitiendo obtener los datos demográficos del paciente para insertarlo en el mensaje HL7 de salida.
57

Soluciones

La creación de esta base de datos y tablas fue realizada mediante el programa MySQL-Front el cual es un entorno grafico para la creación de base de datos. Más información se puede encontrar en la siguiente página web. 
http://www.mysqlfront.de/

Con esto finalizaríamos los componentes necesarios para el buen funcionamiento del actor DOR, para una idea más clara de cómo funcionaria dicho actor, la sección siguiente muestra un diagrama, así como la descripción del flujo de trabajo realizado por el DOR. 4.3.2.1.4 Flujo de trabajo del actor DOR.

DB

XML IEEE 11073 - 10103 MDC-IDC

Canal
file_to_channel

DOC

DOR

1

2

3

El archivo en XML con el estándar IEEE 11073 10103 MDC-IDC es almacenado en un directorio disponible en el ordenador donde se ejecuta el sistema integrador Iguana. El canal obtiene sus datos de entrada mediante la lectura de este archivo de manera automática cada vez que existe una nueva versión. El algoritmo creado con el lenguaje LUA empieza a procesar los datos para la formación del mensaje final de igual manera se conecta a la base de datos creada para obtener los datos demográficos del paciente. El canal envía sus datos de salida al actor DOC en formato HL7 de tipo ORU cumpliendo la normativa presentada en el perfil IHE-PCD-IDCO hacia otro canal establecido que hará la función del actor DOC.
58

Soluciones

4.4 Diseño del actor DOC(Device Cardiac Consumer)
El diseño de este actor como se mencionó antes, fue mediante la creación de otro canal en la plataforma Iguana, solamente que las características de configuración fueron diferentes. Este canal fue llamado Channel_to_Db. Además de esta canal, para demostrar que los datos cardiacos del paciente habían sido insertados en su correspondiente historial clínico, se necesitaba hacer uso de un sistema gestor de historia clínica que nos permitiera ver estos datos. El sistema usado fue OpenClinic que es un proyecto de código libre orientado a Web, con tecnología PHP, y como base de datos Mysql, el cual tiene una sección que permite llevar un historial médico de pacientes. 4.4.1 Datos de entrada del canal. Desde otro canal existente: Esta opción fue utilizada como datos de entrada, debido a que ya contábamos con un canal (actor DOR) que nos ofrecía a su salida el mensaje codificado en HL7/ORU. Simplemente fue necesario configurar el canal con esta opción para que la salida del actor DOR sea la entrada del actor DOC. La figura 4.10 muestra la configuración de los datos de entrada de este canal.

Figura 4.10. Configuración de datos de entrada del canal

Se puede notar aquí que el nombre File_to_channel es el canal previamente creado para el actor DOR, por lo cual con estas configuraciones ya teníamos resuelto la comunicación entre actores.

59

Soluciones

4.4.2 Datos de salida del canal. Base de Datos: Esta característica del canal nos permitió conectarnos con la base de datos de nuestro sistema gestor de historia clínica ( OpenClinic) para insertar los datos en las tablas correspondientes este sistema.

Figura 4.11. Configuración de datos de salida del canal.

La base de datos a la que se conectaría nuestro actor DOC es la generada por el sistema gestor de historia clínica electrónica llamado Openclinic, este sistema es explicado más adelante con más detalle. De qué manera podríamos procesar el mensaje de entrada en formato HL7/ORU, para insertar la información correspondiente a las tablas de OpenClinic, pues la manera de hacerlo fue que Iguana ofrece un aplicación visual llamada Chamaleon, la cual es una herramienta que nos permite decodificar mensajes HL7 e insertarlos en una base de datos predeterminada con mucha flexibilidad y fácil manejo. Se puede ver en la imagen 4.11 que en la sección Full parser VMD path apunta a un archivo llamado demo.vmd. Bueno este archivo fue el que se tuvo que crear en el programa Chamaleon, que es otro software que nos facilitó el mapeo del mensaje HL7 para poder insertar los datos a la base de datos del sistema OpenClinic fácilmente. En otras palabras este programa sirvió de intermediario entre el mensaje y la base de datos de OpenClinic, facilitando el proceso de inserción, pues no tuvimos que recurrir a programar nuevas interfaces, simplemente desde su interfaz grafica, se configuró todo de manera automática.

60

Soluciones

4.4.2.1

Chamaleon.

Chamaelon es una herramienta informática que permite a desarrolladores de sistemas informáticos médicos agregar funcionalidades de mensajería HL7 a sus aplicaciones. Esta herramienta es muy usada actualmente para el mapeo de mensajes HL7 a base de datos, pues tiene incorporado plantillas de todos los tipos de mensajes disponibles de HL7, así como ya conexiones preestablecidas a base de datos más importantes entre ellas la de Mysql que fue la que usamos en este proyecto.

Figura 4.12. Interfaz gráfica del software Chamaleon.

Como vemos en la imagen anterior gracias a su interfaz gráfica podemos realizar cualquier tipo de mapeo de mensajes HL7, se describe a continuación el diseño y los pasos necesarios para poder descomponer nuestro mensaje de entrada e insertarlo en la base de datos de nuestro gestor de historia clínica “OpenClinic”, por eso es necesario hacer varias cosas. Estos pasos fueron hechos una vez solamente y es lo que contiene el programa demo.vmd que se menciona al inicio de esta sección. Solamente fue necesario crear un programa para todos los mensajes que queríamos procesar, además de que se ejecutaba automáticamente cada vez que llega un mensaje de entrada. Si se requiere más información sobre el software Chamaleon se puede visitar el siguiente enlace:
 http://www.interfaceware.com/chameleon.html

61

Soluciones

62

Soluciones

1

En el programa Chamaleon se inserta un mensaje como plantilla que contenga todos los campos y segmentos necesarios. En nuestro caso se uso el mensaje de salida en formato HL7/ORU a que solamente contenía los campos necesarios. De esta manera solamente el programa funcionaria solo con este tipo de mensajes. Automáticamente una vez que se ha insertado el mensaje de entrada, este programa detecta todos los componentes del mensaje y los separa de manera fácil y organizada permitiéndonos ver la estructura del mensaje en forma de árbol, pudiendo identificar cualquier error de un valor que no siguiera la normativa del perfil IHE-PCD-IDCO. Este paso fue el más importante pues una vez que se tenía el mensaje descompuesto en forma de árbol con los valores de los mensajes disponibles, simplemente fue necesario hacer un mapeo hacia nuestra tabla que contendría la información del mensaje.

2

3

Este proceso es de manera transparente al usuario y no se ejecuta en forma visual, simplemente falta hacer referencia el nombre del archivo en nuestra configuración de salida del canal. Aquí terminaría el diseño del actor DOC con todas sus características importantes, igualmente como en el caso del actor DOR se presenta el flujo de trabajo del actor DOC. 4.4.2.2 Flujo de trabajo del actor DOC.

DB

Canal

DOR

File_to_channel

Chamaleon

DOC

63

Soluciones

1 2

El mensaje en formato HL7/ORU llega la canal de entrada para su procesamiento. Este canal ejecuta automáticamente y en modo de fondo el algoritmo contenido en el programa demo.vmd creado con el software Chamaleon. Esto nos verifica que el mensaje tenga las características deseadas y descarte cualquier otro tipo de mensajes. Si el mensaje es correcto y cumple con los requisitos establecidos, los campos son insertados en la base de datos del programa OpenClinic, que funciona como nuestro gestor de historia clínica. Mediante cualquier navegador se puede acceder al sistema OpenClinic para visualizar los datos. Este punto no está especificado en el perfil IHE-PCD-IDCO, ni en el flujo de trabajo del actor DOC, por lo cual puede ser implementado usando cualquier tipo de tecnología según las necesidades requeridas de cada empresa. Aquí se muestra a manera de ejemplo los datos extraídos del marcapasos mediante el sistema de gestor de información “OpenClinic”.

3

4

De esta manera se tenía ya el diseño de los actores involucrados según el perfil IHEPCD-IDCO. Mencionamos que hasta aquí terminaría la función de este perfil y la etapa de visualización de los datos (punto cuatro del diagrama anterior) es independiente y depende según la tecnología con la que se ha desarrollado el sistema gestor de historia clínica.

4.5 Sistema gestor de historia clínica OpenClinic
OpenClinic es un sistema de registros medico, de fácil manejo, código libre, escrito en el lenguaje PHP y como base de datos Mysql. Cuenta con varios módulos los cuales incluyen características importantes. Modulo de Administración del paciente.     Búsqueda, creación, edición de nuevos pacientes. Datos sociales. Historia clínica. Reporte de problemas.

Modulo de Administrador:     Configuraciones. Editor de plantillas. Control de empleados. Control de usuarios del sistema.
64

Soluciones

  

Logs. Estadísticas. Reporte formato PDF.

Para más información se puede visitar la página del proyecto en la siguiente dirección:  http://openclinic.sourceforge.net/

Para poder ejecutar el programa necesitábamos de un servidor que nos pudiera ejecutar y traducir el código PHP con el que se había creado el programa, además de que tuviera la característica de HTTP para mostrar la pagina desde cualquier navegador. Para resolver este problema se decidió usar un servidor también de licencia libre llamado Apache. 4.5.1 Servidor Web Apache. Apache es el servidor web más popular, junto con MySQL y los lenguajes de programación PHP/Perl/Python. Características de Apache:      Soporte para los lenguajes perl, python, PHP. Módulos de autenticación: mod_access, mod_auth y mod_digest. Soporte para SSL y TLS. Permite la configuración de mensajes de errores personalizados y negociación de contenido. Permite autenticación de base de datos basada en SGBD. Arquitectura del servidor Apache.

4.5.1.1

La arquitectura del servidor Apache es un software que está estructurado en módulos. La configuración de cada módulo se hace mediante la configuración de las directivas que están contenidas dentro del módulo. Estos módulos se pueden clasificar en tres categorías:   Módulos Base: Módulo con las funciones básicas del Apache Módulos Multiproceso: Son los responsables de la unión con los puertos de la máquina, acepando las peticiones y enviando a los hijos a atender a las peticiones. Módulos Adicionales: Cualquier otro módulo que le añada una funcionalidad al servidor.

65

Soluciones

Las funcionalidades más elementales se encuentran en el módulo base, siendo necesario un módulo multiproceso para manejar las peticiones. Se han diseñado varios módulos multiproceso para cada uno de los sistemas operativos sobre los que se ejecuta el Apache, optimizando el rendimiento y rapidez del código. El resto de funcionalidades del servidor se consiguen por medio de módulos adicionales que se pueden cargar. Para añadir un conjunto de utilidades al servidor, simplemente hay que añadirle un módulo, de forma que no es necesario volver a instalar el software [15]. Más información pude ser vista en la siguiente página web:
 www.apache.org

Fue necesario leerse la guía de instalación completa del servidor Apache, para poder configurarlo de manera optima y con las funcionalidades requeridas, que eran ejecución de cogido PHP y manejo de base de datos con Mysql. Este servidor se instaló en el mismo ordenador donde se había instalado el sistema integrador Iguana, aunque en casos reales generalmente es instalado en servidores distintos.

4.5.2 Interfaz OpenClinic. Una vez instalado el servidor apache en el ordenador podemos hacer uso de cualquier navegador para ejecutar el programa con la siguiente dirección http://localhost/openclinic_2, esta como mencionamos antes es solo de prueba y puede ser cambiada por cualquier dirección para uso en caso real. La primera pantalla es la de autentificación del usuario la cual debemos de introducir un usuario y su contraseña correspondiente. (Ver figura 4.13).

Figura 4.13. Pantalla de acceso al sistema Openclinc

66

Soluciones

Esta es la pantalla de acceso podemos encontrar el modulo de historia clínica electrónica que es el que usaremos y modificaremos para poder desplegar los datos del dispositivo cardiaco implantable. (Ver figura 4.14)

Figura 4.14. Pantalla de inicio de OpenClinic

Accediendo al modulo de Historia Clínica podemos acceder al historial de cualquier paciente. Como ejemplo la figura 4.15 muestra un registro con datos de una persona en el sistema.

Figura 4.15. Modulo de Historia Clinica del sistema OpenClinic

67

Soluciones

4.5.3 Base de datos del software OpenClinic. La base de datos del software de OpenClinic se muestra a continuación, en ella están las tablas donde se almacena la información que necesita el programa funcione de manera correcta.

Figura 4.16. Tablas contenidas en la base de datos OpenClinic

68

Soluciones

4.5.4 Modificaciones realizadas a OpenClinic. Aprovechando las ventajas del código libre, se modificó la sección del módulo de historia clínica agregando un pequeño script en el lenguaje de PHP con la finalidad de mostrar los datos del dispositivo cardiaco en esta sección. (Ver figura 4.17)

Figura 4.17.Reporte final en el historial del paciente del sistema Openclinic

Como vemos en la figura anterior es la misma que se mostró en el momento de explicar el sistema OpenClinic, con la diferencia de que tiene añadido una sección nueva llamada Historial de Datos del Marcapaso con una tabla donde se mostrarán los valores del dispositivo cardiaco implantable.
69

Soluciones

A demás de esta pequeña modificación se tuvo que crear una tabla adicional en la base de datos del software OpenClinic. Se muestra a continuación la tabla creada donde se almacenarían los datos del segmento OBX del mensaje HL7 que serian los datos de interés que necesitamos para visualizarlos en la sección que añadimos.

Figura 4.18. Campos de la tabla datos_marcapasos.

El nombre de la tabla fue datos_marcapasos para diferenciarla de las demás existentes. Así concluye la fase de soluciones y diseño de nuestra interfaz.

70

Resultados

5.

RESULTADOS.

Esta sección se presenta los resultados finales del proyecto que son el mensaje final HL7 de tipo ORU, generados a partir del archivo de entrada XML con formato IEEE 11073 10103 MDC IDC y la representación visual de esos datos en el sistema gestor de información hospitalaria OpenClinic. Todos los resultados finales cumplen con las validaciones descritas en la metodología del perfil IHE-PCD-IDCO. Debido a que el mensaje final era demasiado extenso se decidió incluirlo en la sección de anexos (Mensaje final generado por el actor DOR), con la finalidad de poder ser más legible y entendible. Como habíamos mencionado anteriormente, fue necesario de un ordenador para ejecutar el sistema integrador IGUANA donde se ejecutaría la interfaz desarrollada en este proyecto. Se usó un ordenador portátil con Windows 7 como sistema operativo de 4GB de memoria y procesador de 2.0 GHZ, siendo este usado como servidor en donde estarían instalados el sistema integrador IGUANA, el sistema gestor OpenClinic y la base de datos Mysql. Esto se hizo solo para hacer las pruebas correspondientes, ya que en un caso real cada sistema o software es instalado en ordenadores diferentes para mejorar el rendimiento.

71

Resultados

5.1

SISTEMA OPENCLINIC.

Se muestran el reporte final en el sistema gestor de historia clínica OpenClinic en donde se puede ver la sección añadida con los datos provenientes del dispositivo cardiaco implantable. Se observan las siguientes tablas agregadas a la sección de Historial del Marcapasos, aquí están contenidos los datos del mensaje HL7/ORU generado por nuestro actor DOR y procesado por nuestro actor DOC. Nótese que algunos campos no contienen datos esto es debido a que el ejemplo de archivo de entrada no hace uso de ellos.

Datos del paciente:

Nombre del Paciente: Fecha de nacimiento: Sexo:

Cortes Manica Alvaro 06/02/1984 Hombre

Fecha de interrogación, Tipo: Feca de la inerrogacion anterior, Tipo, Program:

01/10/2010 1:39 AM, Remote 20/04/2010 11:50 AM, In-Clinic ,No reprogramado

Nombre del Doctor, Clinic: Contacto:

Thomas Berger, any clinic Fax: +123456

72

Resultados

Datos del dispositivo:
Tipo de Dispositivo: Empresa Manufacturera: Modelo del dispositivo: Numero de serie del dispositivo: Fecha de implante: Dr. que lo implanto/ Lugar: Numero Contacto: ICD Biotronik Lumax 300 VR-T 110011 03/11/2003 11:31:24 No disponible No disponible

Datos del Electrodo:

Lead Ubicacion: Detalles de ubicacion: Fecha de implatacion: Manufacturado por: Modelo: Numero de serie: Polaridad: Estado: Lead Special Function:

Lead 1 RV -05/01/2005 ---Bipolar Conectado --

73

Resultados

Estado de la Batería:

Fecha de revisión de la batería :

01/08/2010 MOS 6.3 V 68.0 %

Estado : Voltaje: Bateria restante (%):

Estado del capacitor:
Fecha de carga: Tiempo de carga (s): Energia de carga: Tipo de Carga: 27/05/2010 8.5 30J Reformation

74

Resultados

Medidas del electrodo:
Dia/fecha de la observación: Medidas del electrodo / Estado 01/08/2010 01:55 - 01/08/2010 01:55

Amplitud intrínseca media: Amplitud intrínseca mínima: Impedancia: Umbral de estimulación:

RV 12.9 mV 12.9 mV

(BP) (BP) (BP) (UP) (BP)

> 440 Ω 0.6 V @ 0.5 ms 0.4 V @ 0.5 ms Método de medida: -Estado del electrodo: Null

75

Resultados

Estadísticas:
Shock Lead Configuration and Measurement

Cátodo- – Ánodo RV RV

Impedancia, Fecha/Time, Tipo de medida Estado 52 Ω, 01/08/2010, low-voltage 28 Ω, 02/26/2010, Shock Null CheckLead

Bradicardia

Taquicardia auricular

3)

Estimulación RA : Estimulación RV : AP-VP: AS-VP: AP-VS: AS-VS:

-10 % ----2)

AT/AF por dia: Max. ModeSw-Epis: Tiempo ModeSw (dias): Numero de ModeSw (dias):

-----

CRT

Estimulación LV : Frecuencia cardiaca de la -aurícula Frecuencia cardiaca del Ventriculo1): 67 bpm Estimulación CRT:

---

76

Resultados

Episodios:
Episodios Terapias

Tipos VF VT1 SVT

Total 9 0 0

Fecha
08/01/2010 01:55:36 08/01/2010 01:55:36 08/01/2010 01:55:36

Tipos Shocks entregados Shocks abortados ATPs

Total 0 9 0

Fecha
08/01/2010 01:55:36 08/01/2010 01:55:36 08/01/2010 01:55:36

Episode List

ID Fecha/Tiempo 1 2 3 4 08/01/2010 01:55:36 08/01/2010 01:55:36 08/01/2010 01:55:36 08/01/2010 01:55:36

Tipo VF VT1 VT SVT

Inducido NO NO NO NO

Configuraciones del Dispositivo:

Config.de Bradicardia

Config. Taquiaritmia auricular

Mode: Rango inferior:

VVI 45 bpm

Modo AT: Rango de cambio Modo AT:

---

Rango de histeresis: -Rango nocturno: Tipo de sensor: -Acelerometro
Config. CRT

Ritmo CRT:

--

77

Resultados

Rango máximo de seguimiento: Rango máximo del sensor: Retraso SAV: PAV Delay:

--

Retraso LV-RV:

--

--

---

Modo de Imán:

Tachyarrhythmia detection therapy temporarily deactivated

Configuraciones de la zona de taquiarritmia

Terapia Ventricular: ON

Terapia OFF Aricular:

Zona

Limite Detection ATP bpm X of Y
195 280 ms 1x Burst

Shocks

Detalles

Status

Vendor

VF

1x 30J, 1x 30J, 6x 30J

No Disponble

Active

BIOZone_VF BIOZone_VT1 BIOZone_VT2

VT1

--

--

--

--

--

Inactivo

VT2

--

--

--

--

--

Inactivo

Lead Channel Settings RV

Sensibilidad: Polaridad: Vector:

1.3 mV Bipolar

(adaptive)

RV Tip – RV Ring
(adaptive)

Estimulación de salida: 4.0 V Ancho de pulso de la estimulación 1 ms

78

Resultados

Con esto comprobamos que el mensaje de entrada es transformado al estándar HL7/ORU para ser insertado en la base de datos del sistema OpenClinic y podemos visualizarlo desde cualquier navegador con la dirección web de prueba que se ha mencionado, De este manera se cuenta con el historial del clínico del paciente actualizado y accesible en cualquier momento. El tiempo de carga del archivo de entrada dependerá de si está o no disponible en el directorio especificado como entrada de datos del canal. Esto es que si no existe un archivo en ese directorio del sistema gestor IGUANA, estaría a la espera de uno de ellos, por lo cual cada segundo estaría revisando el directorio en busca de archivos existentes. Cabe aclarar que esto lo hace de manera automática y transparente al usuario. En esta sección se muestran los datos ya procesados del archivo de entrada. El tiempo que se necesitó para procesar los datos e insertarlos en la base de datos de OpenClinic es diferente y depende mucho de las características del ordenador donde se tiene instalado el sistema integrador y la base de datos MySql, Para este caso en particular la respuesta del procesamiento fue muy rápida y eficaz, esto es debido a que solamente se hicieron pruebas con un solo tipo de mensajes, En casos reales existen muchos más mensajes por lo cual sería necesario hacer pruebas en el sistema para adecuarlo a esos casos reales.

79

Conclusión

6 Conclusiones.
Se pudo cumplir el objetivo principal del proyecto, desarrollando una interfaz sencilla que permitiera una integración automatizada. Está claro que en nuestras opciones principales era la de usar software de código abierto con licencia libres, pero no hubo alguno que nos ofrecieras las funcionalidades que se requerían para el proyecto. El caso del sistema integrador Mirth fue difícil la curva de aprendizaje pues no existía suficientes manuales o ayudas para entender bien el funcionamiento de este sistema, se tuvo que experimentar mucho tiempo para poder llegar a entender el funcionamiento. Una vez ya sabiendo cómo manejar el sistema, se hicieron algunas pruebas de funcionalidad probando algunos mensajes en formato HL7 e insertándolos en la base de datos, esto se pudo hacer mediante un pequeño script hecho en Java, el problema y fue por el cual no decidimos usar este software, es que la versión Mirth 1.8 no permitía importar archivos XML con formatos diferentes que el HL7/XML. Sin duda Mirth es una buena opción para realizar integración sencillas y rápidas, pues cuentan con herramientas que facilitan el trabajo, el inconveniente es que se tiene que usar java para poder filtrar y mapear los mensaje finales, esto causaría que el mantenimiento se mucho mayor y más complicado. Para el sistema Iguana, fue totalmente diferente con respecto al sistema Mirth, pues en su página web contiene muchísima información relacionada con la configuración, manejo, uso de herramientas, tutoriales interactivos, videos, foros de ayuda, código de ejemplo y muchas otras cosas donde se podían buscar información de cualquier tipo referente al sistema. Sin duda la curva de aprendizaje fue muy rápida, inclusive aprender el nuevo lenguaje LUA que se uso para hacer las transformación del mensaje final HL7/ORU fue prácticamente fácil gracias al ambiente de desarrollo integrado en Iguana que permite la codificación y al mismo tiempo la ejecución del código sabiendo en tiempo real la lógica de tu algoritmo. Los actores DOR y DOC como ya mencionamos quedaron implementados dentro del sistema IGUANA asignados a cada uno un canal con sus datos de entrada y salida correspondientes, estos canales funcionaron automáticamente, solo fue necesario poner el archivo con los datos del marcapasos en una carpeta en el ordenador. La dirección del archivo se configuro en la sección de ajustes del canal de entrada de actor DOR. Los resultados fueron los esperados pues se pudo obtener una salida con un mensaje HL7 siguiendo la normativa del perfil IHE-PCD-ICDO. El uso de OpenClinic como sistema gestor de historia clínica fue de gran ayuda pues permitió simular una historia clínica de un paciente, con los datos del marcapasos. Este trabajo ofreció un gran conocimiento sobre el área de integración de sistemas médicos usando los perfiles de la asociación IHE, aunque en este proyecto solo se desarrolló un perfil de implementación, se obtuvieron las bases necesarias para un futuro desarrollo de proyectos de integración sobre otras áreas de la medicina usando diferentes perfiles del IHE.
80

Conclusión

Las limitaciones más importantes que se presentaron es que es necesario contar con el archivo de entrada con formato IEEE 11073 – 10103- MDC-IDC, y en muchas ocasiones los programadores o sistemas de información cardiaca no proporcionan este archivo, por lo cual la interfaz no pudiera ser de gran utilidad pues el perfil IHEPCD-IDCO se basa en este tipo de archivos para su desarrollo. Otro punto importante a considerar como limitación es que la licencia del software IGUANA es solamente de 30 días, después de este periodo se tiene que pagar una licencia comercial para seguir usándolo, aunque no es un impedimento el pago de la licencia uno de los objetivos del proyecto era el desarrollo de la interfaz usando software libre, pero debido a que el sistema integrador IGUANA presenta características muy elevadas a los demás sistemas integradores, su uso en el desarrollo de este proyecto es justificable. De igual manera el archivo a procesar debe estar contenido en el directorio establecido en la configuración de entrada del canal de actor DOR, en un caso remoto el paciente tendría que enviar el archivo para ser descargado manualmente en el directorio correspondiente para su procesamiento. Esto puede ser resuelto configurando el actor DOR para que reciba sus datos desde una dirección FTP, de esta manera sería más rápido el proceso de integración. Esta última acción no se pudo implementar por falta de tiempo. El algoritmo creado en lenguaje LUA para el transformador del mensaje HL7 puede ser usado para procesar datos de otro tipo de fabricante de marcapasos con solo pequeñas modificaciones, mejorando de esta manera el mantenimiento y haciéndolo escalable a mas dispositivos existentes en el mercado. Los conocimientos técnicos aprendidos aquí fueron muy valiosos y diversificado, pues se necesito aprender nuevos lenguajes de programación, configurar base de datos, aprender a usar herramientas para la generación de mensajes HL7, aprender tutoriales sobre el funcionamiento y manejo de los sistemas integradores y de igual manera aprender los estándares HL7 y IEEE 11073 - 10103 - MDC-IDC. Sin duda los perfiles de la asociación IHE ofrecen una manera sencilla de resolver los problemas de interoperabilidad en los sistemas médicos existentes.

81

Anexos

7 Anexos Nomenclatura IEEE 11073 MDC_IDC
Reference ID MDC_IDC_PG_TYPE Systematic Name type | pulse generator | implantable device cardiac | medical device communication model | pulse generator | implantable device cardiac | medical device communication serial number | pulse generator | implantable device cardiac | medical device communication manufacturer | pulse generator | implantable device cardiac | medical device communication implant date | pulse generator | implantable device cardiac | medical device communication implanter | pulse generator | implantable device cardiac | medical device communication implanter contact information | pulse generator | implantable device cardiac | medical device communication implanting facility | pulse generator | implantable device cardiac | medical device communication model | lead | implantable device cardiac | medical device communication serial number | lead | implantable device cardiac | medical device communication manufacturer | lead | implantable device cardiac | medical device communication implant date | lead | implantable device cardiac | medical device communication polarity type | lead | implantable device cardiac | medical device communication location | lead | implantable device cardiac | medical device communication detail 1 | location | lead | implantable device cardiac | medical device communication detail 2 | location | lead | implantable device cardiac | medical device communication detail 3 | location | lead | implantable device cardiac Code 72089 7 Enumeration MDC_IDC_ENUM_DEVICE_TYPE

MDC_IDC_PG_MODEL

72089 8

MDC_IDC_PG_SERIAL

72089 9

MDC_IDC_PG_MFG

72090 0

MDC_IDC_ENUM_MFG

MDC_IDC_PG_IMPLANT_DT

72090 1

MDC_IDC_PG_IMPLANTER

72090 2

MDC_IDC_PG_IMPLANTER_CONTACT_INFO

72090 3

MDC_IDC_PG_IMPLANTING_FACILITY

72090 4

MDC_IDC_LEAD_MODEL

72096 1 72096 2

MDC_IDC_LEAD_SERIAL

MDC_IDC_LEAD_MFG

72096 3

MDC_IDC_ENUM_MFG

MDC_IDC_LEAD_IMPLANT_DT

72096 4

MDC_IDC_LEAD_POLARITY_TYPE

72096 5

MDC_IDC_ENUM_LEAD_POLARITY _TYPE

MDC_IDC_LEAD_LOCATION

72096 6

MDC_IDC_ENUM_LEAD_LOCATION _CHAMBER

MDC_IDC_LEAD_LOCATION_DETAIL_1

72096 7

MDC_IDC_ENUM_LEAD_LOCATION _DETAIL

MDC_IDC_LEAD_LOCATION_DETAIL_2

72096 8

MDC_IDC_ENUM_LEAD_LOCATION _DETAIL

MDC_IDC_LEAD_LOCATION_DETAIL_3

72096 9

MDC_IDC_ENUM_LEAD_LOCATION _DETAIL

82

Anexos

MDC_IDC_LEAD_CONNECTION_STATUS

MDC_IDC_LEAD_SPECIAL_FUNCTION

MDC_IDC_SESS_DTM

MDC_IDC_SESS_TYPE

MDC_IDC_SESS_REPROGRAMMED

MDC_IDC_SESS_DTM_PREVIOUS

MDC_IDC_SESS_TYPE_PREVIOUS

MDC_IDC_SESS_REPROGRAMMED_PREVIOUS

MDC_IDC_SESS_CLINICIAN_NAME

MDC_IDC_SESS_CLINICIAN_CONTACT_INFORMATION

MDC_IDC_SESS_CLINIC_NAME

MDC_IDC_MSMT_DTM

MDC_IDC_MSMT_DTM_START

MDC_IDC_MSMT_DTM_END

MDC_IDC_MSMT_BATTERY_DTM

MDC_IDC_MSMT_BATTERY_STATUS

MDC_IDC_MSMT_BATTERY_VOLTAGE

MDC_IDC_MSMT_BATTERY_IMPEDANCE

| medical device communication connection status | lead | implantable device cardiac | medical device communication special function | lead | implantable device cardiac | medical device communication date time | session | implantable device cardiac | medical device communication type | session | implantable device cardiac | medical device communication reprogrammed | session | implantable device cardiac | medical device communication previous date time | session | implantable device cardiac | medical device communication previous type | session | implantable device cardiac | medical device communication reprogrammed previous | session | implantable device cardiac | medical device communication clinician name | session | implantable device cardiac | medical device communication clinician contact information | session | implantable device cardiac | medical device communication clinic name | session | implantable device cardiac | medical device communication date time | measurement | implantable device cardiac | medical device communication date time | measurement | implantable device cardiac | medical device communication start date time | measurement | implantable device cardiac | medical device communication end date time | battery | measurement | implantable device cardiac | medical device communication status | battery | measurement | implantable device cardiac | medical device communication voltage | battery | measurement | implantable device cardiac | medical device communication impedance | battery | measurement |

72097 0

MDC_IDC_ENUM_LEAD_STATUS

72097 1

72102 5

72102 6

MDC_IDC_ENUM_SESS_TYPE

72102 7

MDC_IDC_ENUM_SESS_REPROGR AMMED

72102 8

72102 9

MDC_IDC_ENUM_SESS_TYPE

72103 0

MDC_IDC_ENUM_SESS_REPROGR AMMED

72103 1

72103 2

72103 3

72115 2

72115 3

72115 4

72121 6

72128 0

MDC_IDC_ENUM_BATTERY_STAT US

72134 4

72140 8

83

Anexos

MDC_IDC_MSMT_BATTERY_REMAINING_LONGEVITY

MDC_IDC_MSMT_BATTERY_REMAINING_PERCENTAGE

MDC_IDC_MSMT_BATTERY_RRT_TRIGGER

MDC_IDC_MSMT_CAP_CHARGE_DTM

MDC_IDC_MSMT_CAP_CHARGE_TIME

MDC_IDC_MSMT_CAP_CHARGE_ENERGY

MDC_IDC_MSMT_CAP_CHARGE_TYPE

MDC_IDC_MSMT_LEADCHNL_RA_DTM

MDC_IDC_MSMT_LEADCHNL_RA_DTM_START

MDC_IDC_MSMT_LEADCHNL_RA_DTM_END

MDC_IDC_MSMT_LEADCHNL_RV_DTM

MDC_IDC_MSMT_LEADCHNL_RV_DTM_START

MDC_IDC_MSMT_LEADCHNL_RV_DTM_END

MDC_IDC_MSMT_LEADCHNL_LA_DTM

implantable device cardiac | medical device communication remaining longevity | battery | measurement | implantable device cardiac | medical device communication remaining percentage | battery | measurement | implantable device cardiac | medical device communication recommended replacement time trigger | battery | measurement | implantable device cardiac | medical device communication last charge date time | capacitor | measurement | implantable device cardiac | medical device communication charge time | capacitor | measurement | implantable device cardiac | medical device communication charge energy | capacitor | measurement | implantable device cardiac | medical device communication charge type | capacitor | measurement | implantable device cardiac | medical device communication date time | lead channel right atrial | measurement | implantable device cardiac | medical device communication date time start | lead channel right atrial | measurement | implantable device cardiac | medical device communication date time end | lead channel right atrial | measurement | implantable device cardiac | medical device communication date time | lead channel right ventricle | measurement | implantable device cardiac | medical device communication date time start | lead channel right ventricle | measurement | implantable device cardiac | medical device communication date time end | lead channel right ventricle | measurement | implantable device cardiac | medical device communication date time | lead channel left atrial | measurement | implantable device cardiac

72147 2

72153 6

72160 0

72166 4

72172 8

72179 2

72185 6

MDC_IDC_ENUM_CHARGE_TYPE

72192 0

72192 1

72192 2

72192 4

72192 5

72192 6

72192 8

84

Anexos

MDC_IDC_MSMT_LEADCHNL_LA_DTM_START

MDC_IDC_MSMT_LEADCHNL_LA_DTM_END

MDC_IDC_MSMT_LEADCHNL_LV_DTM

MDC_IDC_MSMT_LEADCHNL_LV_DTM_START

MDC_IDC_MSMT_LEADCHNL_LV_DTM_END

MDC_IDC_MSMT_LEADCHNL_RA_LEAD_CHANNEL_STAT US

MDC_IDC_MSMT_LEADCHNL_RV_LEAD_CHANNEL_STAT US

MDC_IDC_MSMT_LEADCHNL_LA_LEAD_CHANNEL_STAT US

MDC_IDC_MSMT_LEADCHNL_LV_LEAD_CHANNEL_STATU S

MDC_IDC_MSMT_LEADCHNL_RA_SENSING_INTR_AMPL

MDC_IDC_MSMT_LEADCHNL_RA_SENSING_INTR_AMPL_ MAX

MDC_IDC_MSMT_LEADCHNL_RA_SENSING_INTR_AMPL_ MIN

MDC_IDC_MSMT_LEADCHNL_RA_SENSING_INTR_AMPL_ MEAN

| medical device communication date time start | lead channel left atrial | measurement | implantable device cardiac | medical device communication date time end | lead channel left atrial | measurement | implantable device cardiac | medical device communication date time | lead channel left ventricle | measurement | implantable device cardiac | medical device communication date time start | lead channel left ventricle | measurement | implantable device cardiac | medical device communication date time end | lead channel left ventricle | measurement | implantable device cardiac | medical device communication lead channel status | lead channel right atrial | measurement | implantable device cardiac | medical device communication lead channel status | lead channel right ventricle | measurement | implantable device cardiac | medical device communication lead channel status | lead channel left atrial | measurement | implantable device cardiac | medical device communication lead channel status | lead channel left ventricle | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude | lead channel right atrial | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude maximum | lead channel right atrial | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude minimum | lead channel right atrial | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude mean | lead channel right atrial | measurement |

72192 9

72193 0

72193 2

72193 3

72193 4

72198 4

MDC_IDC_ENUM_CHANNEL_STAT US

72198 5

MDC_IDC_ENUM_CHANNEL_STAT US

72198 6

MDC_IDC_ENUM_CHANNEL_STAT US

72198 7

MDC_IDC_ENUM_CHANNEL_STAT US

72204 8

72204 9

72205 0

72205 1

85

Anexos

MDC_IDC_MSMT_LEADCHNL_RV_SENSING_INTR_AMPL

MDC_IDC_MSMT_LEADCHNL_RV_SENSING_INTR_AMPL_ MAX

MDC_IDC_MSMT_LEADCHNL_RV_SENSING_INTR_AMPL_ MIN

MDC_IDC_MSMT_LEADCHNL_RV_SENSING_INTR_AMPL_ MEAN

MDC_IDC_MSMT_LEADCHNL_LA_SENSING_INTR_AMPL

MDC_IDC_MSMT_LEADCHNL_LA_SENSING_INTR_AMPL_ MAX

MDC_IDC_MSMT_LEADCHNL_LA_SENSING_INTR_AMPL_ MIN

MDC_IDC_MSMT_LEADCHNL_LA_SENSING_INTR_AMPL_ MEAN

MDC_IDC_MSMT_LEADCHNL_LV_SENSING_INTR_AMPL

MDC_IDC_MSMT_LEADCHNL_LV_SENSING_INTR_AMPL_ MAX

MDC_IDC_MSMT_LEADCHNL_LV_SENSING_INTR_AMPL_ MIN

MDC_IDC_MSMT_LEADCHNL_LV_SENSING_INTR_AMPL_ MEAN

implantable device cardiac | medical device communication sensing intrinsic amplitude | lead channel right ventricle | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude maximum | lead channel right ventricle | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude minimum | lead channel right ventricle | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude mean | lead channel right ventricle | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude | lead channel left atrial | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude maximum | lead channel left atrial | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude minimum | lead channel left atrial | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude mean | lead channel left atrial | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude | lead channel left ventricle | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude maximum | lead channel left ventricle | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude minimum | lead channel left ventricle | measurement | implantable device cardiac | medical device communication sensing intrinsic amplitude mean | lead channel left ventricle | measurement | implantable device cardiac

72205 2

72205 3

72205 4

72205 5

72205 6

72205 7

72205 8

72205 9

72206 0

72206 1

72206 2

72206 3

86

Anexos

MDC_IDC_MSMT_LEADCHNL_RA_SENSING_POLARITY

MDC_IDC_MSMT_LEADCHNL_RV_SENSING_POLARITY

MDC_IDC_MSMT_LEADCHNL_LA_SENSING_POLARITY

MDC_IDC_MSMT_LEADCHNL_LV_SENSING_POLARITY

MDC_IDC_MSMT_LEADCHNL_RA_PACING_THRESHOLD_ AMPLITUDE

MDC_IDC_MSMT_LEADCHNL_RV_PACING_THRESHOLD_A MPLITUDE

MDC_IDC_MSMT_LEADCHNL_LA_PACING_THRESHOLD_A MPLITUDE

MDC_IDC_MSMT_LEADCHNL_LV_PACING_THRESHOLD_A MPLITUDE

MDC_IDC_MSMT_LEADCHNL_RA_PACING_THRESHOLD_P ULSEWIDTH

MDC_IDC_MSMT_LEADCHNL_RV_PACING_THRESHOLD_P ULSEWIDTH

MDC_IDC_MSMT_LEADCHNL_LA_PACING_THRESHOLD_P ULSEWIDTH

MDC_IDC_MSMT_LEADCHNL_LV_PACING_THRESHOLD_P ULSEWIDTH

| medical device communication sensing polarity | lead channel right atrial | measurement | implantable device cardiac | medical device communication sensing polarity | lead channel right ventricle | measurement | implantable device cardiac | medical device communication sensing polarity | lead channel left atrial | measurement | implantable device cardiac | medical device communication sensing polarity | lead channel left ventricle | measurement | implantable device cardiac | medical device communication amplitude | pacing threshold | lead channel right atrial | measurement | implantable device cardiac | medical device communication amplitude | pacing threshold | lead channel right ventricle | measurement | implantable device cardiac | medical device communication amplitude | pacing threshold | lead channel left atrial | measurement | implantable device cardiac | medical device communication amplitude | pacing threshold | lead channel left ventricle | measurement | implantable device cardiac | medical device communication pulsewidth | pacing threshold | lead channel right atrial | measurement | implantable device cardiac | medical device communication pulsewidth | pacing threshold | lead channel right ventricle | measurement | implantable device cardiac | medical device communication pulsewidth | pacing threshold | lead channel left atrial | measurement | implantable device cardiac | medical device communication pulsewidth | pacing threshold | lead channel left ventricle | measurement | implantable device cardiac | medical device

72211 2

MDC_IDC_ENUM_POLARITY

72211 3

MDC_IDC_ENUM_POLARITY

72211 4

MDC_IDC_ENUM_POLARITY

72211 5

MDC_IDC_ENUM_POLARITY

72217 6

72217 7

72217 8

72217 9

72224 0

72224 1

72224 2

72224 3

87

Anexos

communication MDC_IDC_MSMT_LEADCHNL_RA_PACING_THRESHOLD_ MEASUREMENT_METHOD measurement method | pacing threshold | lead channel right atrial | measurement | implantable device cardiac | medical device communication measurement method | pacing threshold | lead channel right ventricle | measurement | implantable device cardiac | medical device communication measurement method | pacing threshold | lead channel left atrial | measurement | implantable device cardiac | medical device communication measurement method | pacing threshold | lead channel left ventricle | measurement | implantable device cardiac | medical device communication polarity | pacing threshold | lead channel right atrial | measurement | implantable device cardiac | medical device communication polarity | pacing threshold | lead channel right ventricle | measurement | implantable device cardiac | medical device communication polarity | pacing threshold | lead channel left atrial | measurement | implantable device cardiac | medical device communication polarity | pacing threshold | lead channel left ventricle | measurement | implantable device cardiac | medical device communication value | impedance | lead channel right atrial | measurement | implantable device cardiac | medical device communication value | impedance | lead channel right ventricle | measurement | implantable device cardiac | medical device communication value | impedance | lead channel left atrial | measurement | implantable device cardiac | medical device communication value | impedance | lead channel left ventricle | measurement | implantable device cardiac | medical device 72230 4 MDC_IDC_ENUM_MEASUREMENT_ METHOD

MDC_IDC_MSMT_LEADCHNL_RV_PACING_THRESHOLD_ MEASUREMENT_METHOD

72230 5

MDC_IDC_ENUM_MEASUREMENT_ METHOD

MDC_IDC_MSMT_LEADCHNL_LA_PACING_THRESHOLD_ MEASUREMENT_METHOD

72230 6

MDC_IDC_ENUM_MEASUREMENT_ METHOD

MDC_IDC_MSMT_LEADCHNL_LV_PACING_THRESHOLD_M EASUREMENT_METHOD

72230 7

MDC_IDC_ENUM_MEASUREMENT_ METHOD

MDC_IDC_MSMT_LEADCHNL_RA_PACING_THRESHOLD_P OLARITY

72236 8

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_RV_PACING_THRESHOLD_P OLARITY

72236 9

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_LA_PACING_THRESHOLD_P OLARITY

72237 0

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_LV_PACING_THRESHOLD_P OLARITY

72237 1

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_RA_IMPEDANCE_VALUE

72243 2

MDC_IDC_MSMT_LEADCHNL_RV_IMPEDANCE_VALUE

72243 3

MDC_IDC_MSMT_LEADCHNL_LA_IMPEDANCE_VALUE

72243 4

MDC_IDC_MSMT_LEADCHNL_LV_IMPEDANCE_VALUE

72243 5

88

Anexos

communication MDC_IDC_MSMT_LEADCHNL_RA_IMPEDANCE_POLARITY polarity | impedance | lead channel right atrial | measurement | implantable device cardiac | medical device communication polarity | impedance | lead channel right ventricle | measurement | implantable device cardiac | medical device communication polarity | impedance | lead channel left atrial | measurement | implantable device cardiac | medical device communication polarity | impedance | lead channel left ventricle | measurement | implantable device cardiac | medical device communication date time | lead high voltage channel | measurement | implantable device cardiac | medical device communication date time start | lead high voltage channel | measurement | implantable device cardiac | medical device communication date time end | lead high voltage channel | measurement | implantable device cardiac | medical device communication impedance | lead high voltage channel | measurement | implantable device cardiac | medical device communication measurement type | lead high voltage channel | measurement | implantable device cardiac | medical device communication status | lead high voltage channel | measurement | implantable device cardiac | medical device communication cardiac resynchronization therapy left ventricle right ventricle delay | setting | implantable device cardiac | medical device communication cardiac resynchronization therapy paced chambers | setting | implantable device cardiac | medical device communication magnet response | setting | implantable device cardiac | medical device communication 72249 6 MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_RV_IMPEDANCE_POLARITY

72249 7

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_LA_IMPEDANCE_POLARITY

72249 8

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_LV_IMPEDANCE_POLARITY

72249 9

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADHVCHNL_DTM

72256 0

MDC_IDC_MSMT_LEADHVCHNL_DTM_START

72256 1

MDC_IDC_MSMT_LEADHVCHNL_DTM_END

72256 2

MDC_IDC_MSMT_LEADHVCHNL_IMPEDANCE

72262 4

MDC_IDC_MSMT_LEADHVCHNL_MEASUREMENT_TYPE

72268 8

MDC_IDC_ENUM_HVCHNL_MEASU REMENT_TYPE

MDC_IDC_MSMT_LEADHVCHNL_STATUS

72275 2

MDC_IDC_ENUM_CHANNEL_STAT US

MDC_IDC_SET_CRT_LVRV_DELAY

72934 4

MDC_IDC_SET_CRT_PACED_CHAMBERS

72940 8

MDC_IDC_ENUM_CRT_PACED_CH AMBERS

MDC_IDC_SET_MAGNET_RESP

72947 2

89

Anexos

MDC_IDC_SET_LEADCHNL_RA_SENSING_SENSITIVITY

MDC_IDC_SET_LEADCHNL_RV_SENSING_SENSITIVITY

MDC_IDC_SET_LEADCHNL_LA_SENSING_SENSITIVITY

MDC_IDC_SET_LEADCHNL_LV_SENSING_SENSITIVITY

MDC_IDC_SET_LEADCHNL_RA_SENSING_POLARITY

MDC_IDC_SET_LEADCHNL_RV_SENSING_POLARITY

MDC_IDC_SET_LEADCHNL_LA_SENSING_POLARITY

MDC_IDC_SET_LEADCHNL_LV_SENSING_POLARITY

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_LOCAT ION

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_LOCAT ION_1

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_LOCAT ION_2

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_LOCAT ION_3

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_LOCATI ON

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_LOCATI ON_1

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_LOCATI ON_2

sensitivity | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication sensitivity | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication sensitivity | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication sensitivity | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication polarity | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication polarity | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication polarity | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication polarity | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode location | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode location 1 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode location 2 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode location 3 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode location | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode location 1 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode location 2 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

72953 6

72953 7

72953 8

72953 9

72960 0

MDC_IDC_ENUM_POLARITY

72960 1

MDC_IDC_ENUM_POLARITY

72960 2

MDC_IDC_ENUM_POLARITY

72960 3

MDC_IDC_ENUM_POLARITY

72966 4

72966 5

72966 6

72966 7

72968 0

72968 1

72968 2

90

Anexos

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_LOCATI ON_3

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_LOCATI ON

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_LOCATI ON_1

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_LOCATI ON_2

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_LOCATI ON_3

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_LOCATI ON

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_LOCATI ON_1

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_LOCATI ON_2

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_LOCATI ON_3

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_ELECT RODE

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_ELECT RODE_1

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_ELECT RODE_2

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_ELECT RODE_3

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_ELECT RODE

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_ELECT RODE_1

anode location 3 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode location | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode location 1 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode location 2 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode location 3 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode location | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode location 1 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode location 2 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode location 3 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode electrode | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode electrode 1 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode electrode 2 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode electrode 3 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode electrode | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode electrode 1 | sensing | lead channel right ventricle | setting |

72968 3

72969 6

72969 7

72969 8

72969 9

72971 2

72971 3

72971 4

72971 5

72972 8

72972 9

72973 0

72973 1

72974 4

72974 5

91

Anexos

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_ELECT RODE_2

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_ELECT RODE_3

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_ELECT RODE

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_ELECT RODE_1

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_ELECT RODE_2

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_ELECT RODE_3

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_ELECT RODE

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_ELECT RODE_1

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_ELECT RODE_2

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_ELECT RODE_3

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_LOC ATION

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_LOC ATION_1

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_LOC ATION_2

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_LOC ATION_3

implantable device cardiac | medical device communication anode electrode 2 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode electrode 3 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode electrode | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode electrode 1 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode electrode 2 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode electrode 3 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode electrode | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode electrode 1 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode electrode 2 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode electrode 3 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode location | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode location 1 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode location 2 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode location 3 | sensing | lead channel

72974 6

72974 7

72976 0

72976 1

72976 2

72976 3

72977 6

72977 7

72977 8

72977 9

72979 2

72979 3

72979 4

72979 5

92

Anexos

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_LOC ATION

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_LOC ATION_1

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_LOC ATION_2

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_LOC ATION_3

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_LOC ATION

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_LOC ATION_1

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_LOC ATION_2

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_LOC ATION_3

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_LOC ATION

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_LOC ATION_1

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_LOC ATION_2

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_LOC ATION_3

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_ELE CTRODE

right atrial | setting | implantable device cardiac | medical device communication cathode location | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode location 1 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode location 2 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode location 3 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode location | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode location 1 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode location 2 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode location 3 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode location | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode location 1 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode location 2 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode location 3 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode electrode | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

72980 8

72980 9

72981 0

72981 1

72982 4

72982 5

72982 6

72982 7

72984 0

72984 1

72984 2

72984 3

72985 6

93

Anexos

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_ELE CTRODE_1

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_ELE CTRODE_2

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_ELE CTRODE_3

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_ELE CTRODE

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_ELE CTRODE_1

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_ELE CTRODE_2

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_ELE CTRODE_3

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_ELE CTRODE

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_ELE CTRODE_1

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_ELE CTRODE_2

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_ELE CTRODE_3

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_ELE CTRODE

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_ELE CTRODE_1

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_ELE CTRODE_2

cathode electrode 1 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode electrode 2 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode electrode 3 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode electrode | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode electrode 1 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode electrode 2 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode electrode 3 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode electrode | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode electrode 1 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode electrode 2 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode electrode 3 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode electrode | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode electrode 1 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode electrode 2 | sensing | lead channel left ventricle | setting |

72985 7

72985 8

72985 9

72987 2

72987 3

72987 4

72987 5

72988 8

72988 9

72989 0

72989 1

72990 4

72990 5

72990 6

94

Anexos

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_ELE CTRODE_3

MDC_IDC_SET_LEADCHNL_RA_SENSING_ADAPTATION_ MODE

MDC_IDC_SET_LEADCHNL_RV_SENSING_ADAPTATION_ MODE

MDC_IDC_SET_LEADCHNL_LA_SENSING_ADAPTATION_M ODE

MDC_IDC_SET_LEADCHNL_LV_SENSING_ADAPTATION_M ODE

MDC_IDC_SET_LEADCHNL_RA_PACING_AMPLITUDE

MDC_IDC_SET_LEADCHNL_RV_PACING_AMPLITUDE

MDC_IDC_SET_LEADCHNL_LA_PACING_AMPLITUDE

MDC_IDC_SET_LEADCHNL_LV_PACING_AMPLITUDE

MDC_IDC_SET_LEADCHNL_RA_PACING_PULSEWIDTH

MDC_IDC_SET_LEADCHNL_RV_PACING_PULSEWIDTH

MDC_IDC_SET_LEADCHNL_LA_PACING_PULSEWIDTH

MDC_IDC_SET_LEADCHNL_LV_PACING_PULSEWIDTH

MDC_IDC_SET_LEADCHNL_RA_PACING_POLARITY

MDC_IDC_SET_LEADCHNL_RV_PACING_POLARITY

implantable device cardiac | medical device communication cathode electrode 3 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication adaptation mode | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication adaptation mode | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication adaptation mode | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication adaptation mode | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication amplitude | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication amplitude | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication amplitude | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication amplitude | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication pulsewidth | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication pulsewidth | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication pulsewidth | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication pulsewidth | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication polarity | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication polarity | pacing | lead

72990 7

72992 0

MDC_IDC_ENUM_SENSING_ADAPT ION_MODE

72992 1

MDC_IDC_ENUM_SENSING_ADAPT ION_MODE

72992 2

MDC_IDC_ENUM_SENSING_ADAPT ION_MODE

72992 3

MDC_IDC_ENUM_SENSING_ADAPT ION_MODE

72998 4

72998 5

72998 6

72998 7

73004 8

73004 9

73005 0

73005 1

73011 2

MDC_IDC_ENUM_POLARITY

73011

MDC_IDC_ENUM_POLARITY

95

Anexos

MDC_IDC_SET_LEADCHNL_LA_PACING_POLARITY

MDC_IDC_SET_LEADCHNL_LV_PACING_POLARITY

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_LOCATI ON

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_LOCATI ON_1

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_LOCATI ON_2

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_LOCATI ON_3

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_LOCATI ON

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_LOCATI ON_1

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_LOCATI ON_2

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_LOCATI ON_3

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_LOCATI ON

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_LOCATI ON_1

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_LOCATI ON_2

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_LOCATI ON_3

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_LOCATI ON

channel right ventricle | setting | implantable device cardiac | medical device communication polarity | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication polarity | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode location | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode location 1 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode location 2 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode location 3 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode location | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode location 1 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode location 2 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode location 3 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode location | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode location 1 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode location 2 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode location 3 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode location | pacing | lead channel left ventricle |

3

73011 4

MDC_IDC_ENUM_POLARITY

73011 5

MDC_IDC_ENUM_POLARITY

73017 6

73017 7

73017 8

73017 9

73019 2

73019 3

73019 4

73019 5

73020 8

73020 9

73021 0

73021 1

73022 4

96

Anexos

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_LOCATI ON_1

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_LOCATI ON_2

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_LOCATI ON_3

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_ELECTR ODE

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_ELECTR ODE_1

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_ELECTR ODE_2

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_ELECTR ODE_3

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_ELECTR ODE

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_ELECTR ODE_1

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_ELECTR ODE_2

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_ELECTR ODE_3

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_ELECTR ODE

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_ELECTR ODE_1

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_ELECTR ODE_2

setting | implantable device cardiac | medical device communication anode location 1 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode location 2 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode location 3 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode electrode | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode electrode 1 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode electrode 2 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode electrode 3 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication anode electrode | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode electrode 1 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode electrode 2 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode electrode 3 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication anode electrode | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode electrode 1 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode electrode 2 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

73022 5

73022 6

73022 7

73024 0

73024 1

73024 2

73024 3

73025 6

73025 7

73025 8

73025 9

73027 2

73027 3

73027 4

97

Anexos

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_ELECTR ODE_3

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_ELECTR ODE

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_ELECTR ODE_1

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_ELECTR ODE_2

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_ELECTR ODE_3

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_LOCA TION

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_LOCA TION_1

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_LOCA TION_2

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_LOCA TION_3

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_LOCA TION

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_LOCA TION_1

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_LOCA TION_2

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_LOCA TION_3

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_LOCA TION

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_LOCA TION_1

anode electrode 3 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication anode electrode | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode electrode 1 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode electrode 2 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode electrode 3 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode location | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode location 1 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode location 2 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode location 3 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode location | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode location 1 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode location 2 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode location 3 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode location | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode location 1 | pacing | lead channel left atrial | setting | implantable device cardiac | medical

73027 5

73028 8

73028 9

73029 0

73029 1

73030 4

73030 5

73030 6

73030 7

73032 0

73032 1

73032 2

73032 3

73033 6

73033 7

98

Anexos

device communication MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_LOCA TION_2 cathode location 2 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode location 3 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode location | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode location 1 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode location 2 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode location 3 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode electrode | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode electrode 1 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode electrode 2 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode electrode 3 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication cathode electrode | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode electrode 1 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode electrode 2 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication cathode electrode 3 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication 73033 8

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_LOCA TION_3

73033 9

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_LOCA TION

73035 2

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_LOCA TION_1

73035 3

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_LOCA TION_2

73035 4

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_LOCA TION_3

73035 5

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_ELEC TRODE

73036 8

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_ELEC TRODE_1

73036 9

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_ELEC TRODE_2

73037 0

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_ELEC TRODE_3

73037 1

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_ELEC TRODE

73038 4

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_ELEC TRODE_1

73038 5

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_ELEC TRODE_2

73038 6

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_ELEC TRODE_3

73038 7

99

Anexos

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_ELEC TRODE

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_ELEC TRODE_1

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_ELEC TRODE_2

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_ELEC TRODE_3

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_ELEC TRODE

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_ELEC TRODE_1

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_ELEC TRODE_2

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_ELEC TRODE_3

MDC_IDC_SET_LEADCHNL_RA_PACING_CAPTURE_MODE

MDC_IDC_SET_LEADCHNL_RV_PACING_CAPTURE_MODE

MDC_IDC_SET_LEADCHNL_LA_PACING_CAPTURE_MODE

MDC_IDC_SET_LEADCHNL_LV_PACING_CAPTURE_MODE

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ LOCATION

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ LOCATION_1

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ LOCATION_2

cathode electrode | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode electrode 1 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode electrode 2 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode electrode 3 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication cathode electrode | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode electrode 1 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode electrode 2 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication cathode electrode 3 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication capture mode | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication capture mode | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication capture mode | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication capture mode | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication anode location | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication anode location 1 | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication anode location 2 | vector | shock | lead high voltage

73040 0

73040 1

73040 2

73040 3

73041 6

73041 7

73041 8

73041 9

73043 2

MDC_IDC_ENUM_PACING_CAPTU RE_MODE

73043 3

MDC_IDC_ENUM_PACING_CAPTU RE_MODE

73043 4

MDC_IDC_ENUM_PACING_CAPTU RE_MODE

73043 5

MDC_IDC_ENUM_PACING_CAPTU RE_MODE

73049 6

MDC_IDC_ENUM_ELECTRODE_LO CATION

73049 7

MDC_IDC_ENUM_ELECTRODE_LO CATION

73049 8

MDC_IDC_ENUM_ELECTRODE_LO CATION

100

Anexos

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ LOCATION_3

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ ELECTRODE

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ ELECTRODE_1

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ ELECTRODE_2

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ ELECTRODE_3

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHOD E_LOCATION

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHOD E_LOCATION_1

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHOD E_LOCATION_2

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHOD E_LOCATION_3

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHOD E_ELECTRODE

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHOD E_ELECTRODE_1

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHOD E_ELECTRODE_2

channel | setting | implantable device cardiac | medical device communication anode location 3 | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication anode electrode | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication anode electrode 1 | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication anode electrode 2 | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication anode electrode 3 | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication cathode location | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication cathode location 1 | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication cathode location 2 | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication cathode location 3 | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication cathode electrode | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication cathode electrode 1 | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication cathode electrode 2 | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication

73049 9

MDC_IDC_ENUM_ELECTRODE_LO CATION

73056 0

MDC_IDC_ENUM_ELECTRODE_NA ME

73056 1

MDC_IDC_ENUM_ELECTRODE_NA ME

73056 2

MDC_IDC_ENUM_ELECTRODE_NA ME

73056 3

MDC_IDC_ENUM_ELECTRODE_NA ME

73062 4

MDC_IDC_ENUM_ELECTRODE_LO CATION

73062 5

MDC_IDC_ENUM_ELECTRODE_LO CATION

73062 6

MDC_IDC_ENUM_ELECTRODE_LO CATION

73062 7

MDC_IDC_ENUM_ELECTRODE_LO CATION

73068 8

MDC_IDC_ENUM_ELECTRODE_NA ME

73068 9

MDC_IDC_ENUM_ELECTRODE_NA ME

73069 0

MDC_IDC_ENUM_ELECTRODE_NA ME

101

Anexos

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHOD E_ELECTRODE_3

MDC_IDC_SET_BRADY_MODE

MDC_IDC_SET_BRADY_VENDOR_MODE

MDC_IDC_SET_BRADY_LOWRATE

MDC_IDC_SET_BRADY_HYSTRATE

MDC_IDC_SET_BRADY_NIGHT_RATE

MDC_IDC_SET_BRADY_SENSOR_TYPE

MDC_IDC_SET_BRADY_MAX_TRACKING_RATE

MDC_IDC_SET_BRADY_MAX_SENSOR_RATE

MDC_IDC_SET_BRADY_SAV_DELAY

MDC_IDC_SET_BRADY_SAV_DELAY_HIGH

MDC_IDC_SET_BRADY_SAV_DELAY_LOW

MDC_IDC_SET_BRADY_PAV_DELAY

MDC_IDC_SET_BRADY_PAV_DELAY_HIGH

MDC_IDC_SET_BRADY_PAV_DELAY_LOW

MDC_IDC_SET_BRADY_AT_MODE_SWITCH_MODE

MDC_IDC_SET_BRADY_AT_MODE_SWITCH_RATE

MDC_IDC_SET_TACHYTHERAPY_VSTAT

cathode electrode 3 | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication mode | brady | setting | implantable device cardiac | medical device communication mode | brady | setting | implantable device cardiac | medical device communication low rate | brady | setting | implantable device cardiac | medical device communication hysteresis rate | brady | setting | implantable device cardiac | medical device communication night rate | brady | setting | implantable device cardiac | medical device communication sensor type | brady | setting | implantable device cardiac | medical device communication maximum tracking rate | brady | setting | implantable device cardiac | medical device communication maximum sensor rate | brady | setting | implantable device cardiac | medical device communication sav delay | brady | setting | implantable device cardiac | medical device communication sav delay high | brady | setting | implantable device cardiac | medical device communication sav delay low | brady | setting | implantable device cardiac | medical device communication pav delay | brady | setting | implantable device cardiac | medical device communication pav delay high | brady | setting | implantable device cardiac | medical device communication pav delay low | brady | setting | implantable device cardiac | medical device communication atrial tachy mode switch mode | brady | setting | implantable device cardiac | medical device communication atrial tachy mode switch rate | brady | setting | implantable device cardiac | medical device communication ventricular status | tachytherapy | setting |

73069 1

MDC_IDC_ENUM_ELECTRODE_NA ME

73075 2

MDC_IDC_ENUM_BRADY_MODE

73081 6

73088 0

73094 4

73100 8

73107 2

73113 6

73120 0

73126 4

73126 5

73126 6

73132 8

73132 9

73133 0

73139 2

MDC_IDC_ENUM_BRADY_MODE

73145 6

73152 0

MDC_IDC_ENUM_THERAPY_STAT US

102

Anexos

MDC_IDC_SET_TACHYTHERAPY_ASTAT

MDC_IDC_SET_ZONE_TYPE

MDC_IDC_SET_ZONE_VENDOR_TYPE

MDC_IDC_SET_ZONE_STATUS

MDC_IDC_SET_ZONE_DETECTION_INTERVAL

MDC_IDC_SET_ZONE_DETECTION_BEATS_NUMERATOR

MDC_IDC_SET_ZONE_DETECTION_BEATS_DENOMINATO R

MDC_IDC_SET_ZONE_DETECTION_DETAILS

MDC_IDC_SET_ZONE_TYPE_ATP

MDC_IDC_SET_ZONE_TYPE_ATP_1

MDC_IDC_SET_ZONE_TYPE_ATP_2

MDC_IDC_SET_ZONE_TYPE_ATP_3

MDC_IDC_SET_ZONE_TYPE_ATP_4

MDC_IDC_SET_ZONE_TYPE_ATP_5

MDC_IDC_SET_ZONE_TYPE_ATP_6

MDC_IDC_SET_ZONE_TYPE_ATP_7

implantable device cardiac | medical device communication atrial status | tachytherapy | setting | implantable device cardiac | medical device communication type | zone | setting | implantable device cardiac | medical device communication vendor type | zone | setting | implantable device cardiac | medical device communication status | zone | setting | implantable device cardiac | medical device communication detection interval | zone | setting | implantable device cardiac | medical device communication detection beats numerator | zone | setting | implantable device cardiac | medical device communication detection beats denominator | zone | setting | implantable device cardiac | medical device communication detection details | zone | setting | implantable device cardiac | medical device communication type atrial atrial antitachycardia pacing pulse | zone | setting | implantable device cardiac | medical device communication type atrial anti-tachycardia pacing pulse 1 | zone | setting | implantable device cardiac | medical device communication type atrial anti-tachycardia pacing pulse 2 | zone | setting | implantable device cardiac | medical device communication type atrial anti-tachycardia pacing pulse 3 | zone | setting | implantable device cardiac | medical device communication type atrial anti-tachycardia pacing pulse 4 | zone | setting | implantable device cardiac | medical device communication type atrial anti-tachycardia pacing pulse 5 | zone | setting | implantable device cardiac | medical device communication type atrial anti-tachycardia pacing pulse 6 | zone | setting | implantable device cardiac | medical device communication type atrial anti-tachycardia pacing pulse 7 | zone | setting | implantable device cardiac | medical

73158 4

MDC_IDC_ENUM_THERAPY_STAT US

73164 8

MDC_IDC_ENUM_ZONE_TYPE

73171 2

73177 6

MDC_IDC_ENUM_ZONE_STATUS

73184 0

73190 4

73196 8

73203 2

73209 6

MDC_IDC_ENUM_ATP_TYPE

73209 7

MDC_IDC_ENUM_ATP_TYPE

73209 8

MDC_IDC_ENUM_ATP_TYPE

73209 9

MDC_IDC_ENUM_ATP_TYPE

73210 0

MDC_IDC_ENUM_ATP_TYPE

73210 1

MDC_IDC_ENUM_ATP_TYPE

73210 2

MDC_IDC_ENUM_ATP_TYPE

73210 3

MDC_IDC_ENUM_ATP_TYPE

103

Anexos

device communication MDC_IDC_SET_ZONE_TYPE_ATP_8 type atrial anti-tachycardia pacing pulse 8 | zone | setting | implantable device cardiac | medical device communication type atrial anti-tachycardia pacing pulse 9 | zone | setting | implantable device cardiac | medical device communication type atrial anti-tachycardia pacing pulse 10 | zone | setting | implantable device cardiac | medical device communication number of atrial antitachycardia pacing pulse sequences | zone | setting | implantable device cardiac | medical device communication number of atrial antitachycardia pacing pulse sequences 1 | zone | setting | implantable device cardiac | medical device communication number of atrial antitachycardia pacing pulse sequences 2 | zone | setting | implantable device cardiac | medical device communication number of atrial antitachycardia pacing pulse sequences 3 | zone | setting | implantable device cardiac | medical device communication number of atrial antitachycardia pacing pulse sequences 4 | zone | setting | implantable device cardiac | medical device communication number of atrial antitachycardia pacing pulse sequences 5 | zone | setting | implantable device cardiac | medical device communication number of atrial antitachycardia pacing pulse sequences 6 | zone | setting | implantable device cardiac | medical device communication number of atrial antitachycardia pacing pulse sequences 7 | zone | setting | implantable device cardiac | medical device communication number of atrial antitachycardia pacing pulse sequences 8 | zone | setting | implantable device cardiac | medical device communication number of atrial antitachycardia pacing pulse sequences 9 | zone | setting | implantable device cardiac | medical device communication 73210 4 MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_TYPE_ATP_9

73210 5

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_TYPE_ATP_10

73210 6

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_NUM_ATP_SEQS

73216 0

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_1

73216 1

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_2

73216 2

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_3

73216 3

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_4

73216 4

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_5

73216 5

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_6

73216 6

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_7

73216 7

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_8

73216 8

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_9

73216 9

104

Anexos

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_10

MDC_IDC_SET_ZONE_SHOCK_ENERGY

MDC_IDC_SET_ZONE_SHOCK_ENERGY_1

MDC_IDC_SET_ZONE_SHOCK_ENERGY_2

MDC_IDC_SET_ZONE_SHOCK_ENERGY_3

MDC_IDC_SET_ZONE_SHOCK_ENERGY_4

MDC_IDC_SET_ZONE_SHOCK_ENERGY_5

MDC_IDC_SET_ZONE_SHOCK_ENERGY_6

MDC_IDC_SET_ZONE_SHOCK_ENERGY_7

MDC_IDC_SET_ZONE_SHOCK_ENERGY_8

MDC_IDC_SET_ZONE_SHOCK_ENERGY_9

MDC_IDC_SET_ZONE_SHOCK_ENERGY_10

MDC_IDC_SET_ZONE_NUM_SHOCKS

MDC_IDC_SET_ZONE_NUM_SHOCKS_1

MDC_IDC_SET_ZONE_NUM_SHOCKS_2

MDC_IDC_SET_ZONE_NUM_SHOCKS_3

MDC_IDC_SET_ZONE_NUM_SHOCKS_4

MDC_IDC_SET_ZONE_NUM_SHOCKS_5

MDC_IDC_SET_ZONE_NUM_SHOCKS_6

number of atrial antitachycardia pacing pulse sequences 10 | zone | setting | implantable device cardiac | medical device communication shock energy | zone | setting | implantable device cardiac | medical device communication shock energy 1 | zone | setting | implantable device cardiac | medical device communication shock energy 2 | zone | setting | implantable device cardiac | medical device communication shock energy 3 | zone | setting | implantable device cardiac | medical device communication shock energy 4 | zone | setting | implantable device cardiac | medical device communication shock energy 5 | zone | setting | implantable device cardiac | medical device communication shock energy 6 | zone | setting | implantable device cardiac | medical device communication shock energy 7 | zone | setting | implantable device cardiac | medical device communication shock energy 8 | zone | setting | implantable device cardiac | medical device communication shock energy 9 | zone | setting | implantable device cardiac | medical device communication shock energy 10 | zone | setting | implantable device cardiac | medical device communication number of shocks | zone | setting | implantable device cardiac | medical device communication number of shocks 1 | zone | setting | implantable device cardiac | medical device communication number of shocks 2 | zone | setting | implantable device cardiac | medical device communication number of shocks 3 | zone | setting | implantable device cardiac | medical device communication number of shocks 4 | zone | setting | implantable device cardiac | medical device communication number of shocks 5 | zone | setting | implantable device cardiac | medical device communication number of shocks 6 | zone | setting | implantable

73217 0

73222 4

73222 5

73222 6

73222 7

73222 8

73222 9

73223 0

73223 1

73223 2

73223 3

73223 4

73228 8

73228 9

73229 0

73229 1

73229 2

73229 3

73229 4

105

Anexos

MDC_IDC_SET_ZONE_NUM_SHOCKS_7

MDC_IDC_SET_ZONE_NUM_SHOCKS_8

MDC_IDC_SET_ZONE_NUM_SHOCKS_9

MDC_IDC_SET_ZONE_NUM_SHOCKS_10

MDC_IDC_STAT_DTM

MDC_IDC_STAT_DTM_START

MDC_IDC_STAT_DTM_END

MDC_IDC_STAT_HEART_RATE_DTM

MDC_IDC_STAT_HEART_RATE_DTM_START

MDC_IDC_STAT_HEART_RATE_DTM_END

MDC_IDC_STAT_HEART_RATE_ATRIAL

MDC_IDC_STAT_HEART_RATE_ATRIAL_MAX

MDC_IDC_STAT_HEART_RATE_ATRIAL_MIN

MDC_IDC_STAT_HEART_RATE_ATRIAL_MEAN

MDC_IDC_STAT_HEART_RATE_VENTRICULAR

MDC_IDC_STAT_HEART_RATE_VENTRICULAR_MAX

MDC_IDC_STAT_HEART_RATE_VENTRICULAR_MIN

MDC_IDC_STAT_HEART_RATE_VENTRICULAR_MEAN

device cardiac | medical device communication number of shocks 7 | zone | setting | implantable device cardiac | medical device communication number of shocks 8 | zone | setting | implantable device cardiac | medical device communication number of shocks 9 | zone | setting | implantable device cardiac | medical device communication number of shocks 10 | zone | setting | implantable device cardiac | medical device communication date time | statistic | implantable device cardiac | medical device communication date time | statistic | implantable device cardiac | medical device communication start date time | statistic | implantable device cardiac | medical device communication end date time | heart rate | statistic | implantable device cardiac | medical device communication date time start | heart rate | statistic | implantable device cardiac | medical device communication date time end | heart rate | statistic | implantable device cardiac | medical device communication atrial | heart rate | statistic | implantable device cardiac | medical device communication atrial maximum | heart rate | statistic | implantable device cardiac | medical device communication atrial minimum | heart rate | statistic | implantable device cardiac | medical device communication atrial mean | heart rate | statistic | implantable device cardiac | medical device communication ventricular | heart rate | statistic | implantable device cardiac | medical device communication ventricular maximum | heart rate | statistic | implantable device cardiac | medical device communication ventricular minimum | heart rate | statistic | implantable device cardiac | medical device communication ventricular mean | heart rate | statistic | implantable device cardiac | medical device communication

73229 5

73229 6

73229 7

73229 8

73748 8

73748 9

73749 0

73761 6

73761 7

73761 8

73763 2

73763 3

73763 4

73763 5

73764 8

73764 9

73765 0

73765 1

106

Anexos

MDC_IDC_STAT_BRADY_DTM

MDC_IDC_STAT_BRADY_DTM_START

MDC_IDC_STAT_BRADY_DTM_END

MDC_IDC_STAT_BRADY_RA_PERCENT_PACED

MDC_IDC_STAT_BRADY_RV_PERCENT_PACED

MDC_IDC_STAT_BRADY_AP_VP_PERCENT

MDC_IDC_STAT_BRADY_AS_VP_PERCENT

MDC_IDC_STAT_BRADY_AP_VS_PERCENT

MDC_IDC_STAT_BRADY_AS_VS_PERCENT

MDC_IDC_STAT_AT_DTM

MDC_IDC_STAT_AT_DTM_START

MDC_IDC_STAT_AT_DTM_END

MDC_IDC_STAT_AT_MODE_SW_MAX_DURATION

MDC_IDC_STAT_AT_BURDEN_PERCENT

MDC_IDC_STAT_AT_MODE_SW_PERCENT_TIME

MDC_IDC_STAT_AT_MODE_SW_PERCENT_TIME_PER_DA Y

MDC_IDC_STAT_AT_MODE_SW_COUNT

MDC_IDC_STAT_AT_MODE_SW_COUNT_PER_DAY

date time | brady | statistic | implantable device cardiac | medical device communication date time start | brady | statistic | implantable device cardiac | medical device communication date time end | brady | statistic | implantable device cardiac | medical device communication right atrial percent paced | brady | statistic | implantable device cardiac | medical device communication right ventricle percent paced | brady | statistic | implantable device cardiac | medical device communication ap-vp percent | brady | statistic | implantable device cardiac | medical device communication as-vp percent | brady | statistic | implantable device cardiac | medical device communication ap-vs percent | brady | statistic | implantable device cardiac | medical device communication as-vs percent | brady | statistic | implantable device cardiac | medical device communication date time | atrial tachy | statistic | implantable device cardiac | medical device communication date time start | atrial tachy | statistic | implantable device cardiac | medical device communication date time end | atrial tachy | statistic | implantable device cardiac | medical device communication mode switch maximum duration | atrial tachy | statistic | implantable device cardiac | medical device communication burden percent | atrial tachy | statistic | implantable device cardiac | medical device communication mode switch percent of time | atrial tachy | statistic | implantable device cardiac | medical device communication mode switch percent of time per day | atrial tachy | statistic | implantable device cardiac | medical device communication mode switch count | atrial tachy | statistic | implantable device cardiac | medical device communication mode switch count per day

73750 4

73750 5

73750 6

73752 0

73753 6

73755 2

73756 8

73758 4

73760 0

73766 4

73766 5

73766 6

73768 0

73769 6

73771 2

73772 8

73774 4

73776

107

Anexos

MDC_IDC_STAT_CRT_DTM

MDC_IDC_STAT_CRT_DTM_START

MDC_IDC_STAT_CRT_DTM_END

MDC_IDC_STAT_CRT_LV_PERCENT_PACED

MDC_IDC_STAT_CRT_PERCENT_PACED

MDC_IDC_STAT_TACHYTHERAPY_SHOCKS_DELIVERED_ RECENT

MDC_IDC_STAT_TACHYTHERAPY_SHOCKS_DELIVERED_ TOTAL

MDC_IDC_STAT_TACHYTHERAPY_SHOCKS_ABORTED_R ECENT

MDC_IDC_STAT_TACHYTHERAPY_SHOCKS_ABORTED_T OTAL

MDC_IDC_STAT_TACHYTHERAPY_ATP_DELIVERED_REC ENT

MDC_IDC_STAT_TACHYHERAPY_ATP_DELIVERED_TOTA L

MDC_IDC_STAT_TACHYHERAPY_TOTAL_DTM

MDC_IDC_STAT_TACHYHERAPY_TOTAL_DTM_START

MDC_IDC_STAT_TACHYHERAPY_TOTAL_DTM_END

| atrial tachy | statistic | implantable device cardiac | medical device communication date time | cardiac resynchronization therapy | statistic | implantable device cardiac | medical device communication date time | cardiac resynchronization therapy | statistic | implantable device cardiac | medical device communication start date time | cardiac resynchronization therapy | statistic | implantable device cardiac | medical device communication end left ventricle percent paced | cardiac resynchronization therapy | statistic | implantable device cardiac | medical device communication percent paced | cardiac resynchronization therapy | statistic | implantable device cardiac | medical device communication recent shocks delivered | tachy therapy | statistic | implantable device cardiac | medical device communication total shocks delivered | tachy therapy | statistic | implantable device cardiac | medical device communication recent shocks aborted | tachy therapy | statistic | implantable device cardiac | medical device communication total shocks aborted | tachy therapy | statistic | implantable device cardiac | medical device communication recent atrial antitachycardia pacing delivered | tachy therapy | statistic | implantable device cardiac | medical device communication total atrial anti-tachycardia pacing delivered | tachy therapy | statistic | implantable device cardiac | medical device communication date time | total | tachy therapy | statistic | implantable device cardiac | medical device communication date time start | total | tachy therapy | statistic | implantable device cardiac | medical device communication date time end | total | tachy therapy | statistic | implantable device cardiac | medical device

0

73777 6

73777 7

73777 8

73779 2

73780 8

73782 4

73784 0

73785 6

73787 2

73788 8

73790 4

73792 0

73792 1

73792 2

108

Anexos

communication MDC_IDC_STAT_TACHYTHERAPY_RECENT_DTM date time | recent | tachy therapy | statistic | implantable device cardiac | medical device communication date time start | recent | tachy therapy | statistic | implantable device cardiac | medical device communication date time end | recent | tachy therapy | statistic | implantable device cardiac | medical device communication type | episode | statistic | implantable device cardiac | medical device communication type induced | episode | statistic | implantable device cardiac | medical device communication vendor type | episode | statistic | implantable device cardiac | medical device communication recent count | episode | statistic | implantable device cardiac | medical device communication date time | recent | episode | statistic | implantable device cardiac | medical device communication date time start | recent | episode | statistic | implantable device cardiac | medical device communication date time end | recent | episode | statistic | implantable device cardiac | medical device communication total count | episode | statistic | implantable device cardiac | medical device communication date time | total | episode | statistic | implantable device cardiac | medical device communication date time start | total | episode | statistic | implantable device cardiac | medical device communication date time end | total | episode | statistic | implantable device cardiac | medical device communication identifier | episode | implantable device cardiac | medical device communication date time | episode | implantable device cardiac | medical device communication type | episode | implantable device cardiac | medical device 73793 6

MDC_IDC_STAT_TACHYTHERAPY_RECENT_DTM_START

73793 7

MDC_IDC_STAT_TACHYTHERAPY_RECENT_DTM_END

73793 8

MDC_IDC_STAT_EPISODE_TYPE

73795 2

MDC_IDC_ENUM_EPISODE_TYPE

MDC_IDC_STAT_EPISODE_TYPE_INDUCED

73796 8

MDC_IDC_ENUM_EPISODE_TYPE_ INDUCED

MDC_IDC_STAT_EPISODE_VENDOR_TYPE

73798 4

MDC_IDC_STAT_EPISODE_RECENT_COUNT

73800 0

MDC_IDC_STAT_EPISODE_RECENT_COUNT_DTM

73801 6

MDC_IDC_STAT_EPISODE_RECENT_COUNT_DTM_START

73801 7

MDC_IDC_STAT_EPISODE_RECENT_COUNT_DTM_END

73801 8

MDC_IDC_STAT_EPISODE_TOTAL_COUNT

73803 2

MDC_IDC_STAT_EPISODE_TOTAL_COUNT_DTM

73804 8

MDC_IDC_STAT_EPISODE_TOTAL_COUNT_DTM_START

73804 9

MDC_IDC_STAT_EPISODE_TOTAL_COUNT_DTM_END

73805 0

MDC_IDC_EPISODE_ID

73953 6

MDC_IDC_EPISODE_DTM

73955 2

MDC_IDC_EPISODE_TYPE

73956 8

MDC_IDC_ENUM_EPISODE_TYPE

109

Anexos

communication MDC_IDC_EPISODE_TYPE_INDUCED type induced | episode | implantable device cardiac | medical device communication vendor type | episode | implantable device cardiac | medical device communication atrial interval at detection | episode | implantable device cardiac | medical device communication atrial interval at termination | episode | implantable device cardiac | medical device communication ventricular interval at detection | episode | implantable device cardiac | medical device communication ventricular interval at termination | episode | implantable device cardiac | medical device communication detection therapy details | episode | implantable device cardiac | medical device communication therapy result | episode | implantable device cardiac | medical device communication duration | episode | implantable device cardiac | medical device communication 73958 4 MDC_IDC_ENUM_EPISODE_TYPE_ INDUCED

MDC_IDC_EPISODE_VENDOR_TYPE

73960 0

MDC_IDC_EPISODE_ATRIAL_INTERVAL_AT_DETECTION

73961 6

MDC_IDC_EPISODE_ATRIAL_INTERVAL_AT_TERMINATIO N

73963 2

MDC_IDC_EPISODE_VENTRICULAR_INTERVAL_AT_DETE CTION

73964 8

MDC_IDC_EPISODE_VENTRICULAR_INTERVAL_AT_TERMI NATION

73966 4

MDC_IDC_EPISODE_DETECTION_THERAPY_DETAILS

73968 0

MDC_IDC_EPISODE_THERAPY_RESULT

73969 6

MDC_IDC_ENUM_EPISODE_THERA PY_RESULT

MDC_IDC_EPISODE_DURATION

73971 2

110

Anexos

Archivo de entrada usado como ejemplo con la Nomenclatura IEEE 11073 MDC_IDC
<?xml version="1.0" encoding="UTF-8"?> <biotronik-ieee11073-export format-version="2.0" creator="BioHMSC" creator-version="Stage L RC3 NB_20100823"> <dataset> <section name="MDC"> <section name="IDC"> <section name="PG"> <value name="TYPE" type="MDC_IDC_ENUM_DEVICE_TYPE">ICD</value> <value name="MODEL" type="String">Lumax 300 VR-T</value> <value name="SERIAL" type="String">110011</value> <value name="MFG" type="MDC_IDC_ENUM_MFG">BIO</value> <value name="IMPLANT_DT" type="DateTime">20071103T113124</value> </section> <section name="SESS"> <value name="DTM" type="DateTime">20101001T013954+0200</value> <value name="TYPE" type="MDC_IDC_ENUM_SESS_TYPE">Remote</value> <value name="REPROGRAMMED" type="MDC_IDC_ENUM_SESS_REPROGRAMMED">NO</value> <value name="DTM_PREVIOUS" type="DateTime">20100420T115026</value> <value name="TYPE_PREVIOUS" type="MDC_IDC_ENUM_SESS_TYPE">InClinic</value> <value name="CLINICIAN_NAME" type="String">Thomas Berger</value> <value name="CLINICIAN_CONTACT_INFORMATION" type="String">Fax: +123456</value> <value name="CLINIC_NAME" type="String">any clinic</value> </section> <section name="MSMT"> <section name="BATTERY"> <value name="DTM" type="DateTime">20100801T015536</value> <value name="STATUS" type="MDC_IDC_ENUM_BATTERY_STATUS">MOS</value> <value name="REMAINING_PERCENTAGE" type="Numeric" unit="%">68.0</value> </section> <section name="BATTERY"> <value name="DTM" type="DateTime">20100801T000000</value> <value name="VOLTAGE" type="Numeric" unit="V">3.10</value> </section> <section name="CAP"> <value name="CHARGE_DTM" type="DateTime">20100527T000013</value> <value name="CHARGE_TIME" type="Numeric" unit="s">8.5</value> <value name="CHARGE_ENERGY" type="Numeric" unit="J">30</value> <value name="CHARGE_TYPE" type="MDC_IDC_ENUM_CHARGE_TYPE">Reformation</value> </section> <section name="LEADCHNL_RV"> 111

Anexos

<value name="DTM_END" type="DateTime">20100801T015536</value> <value name="LEAD_CHANNEL_STATUS" type="MDC_IDC_ENUM_CHANNEL_STATUS">Null</value> <section name="SENSING"> <value name="INTR_AMPL_MIN" type="Numeric" unit="mV">12.9</value> <value name="INTR_AMPL_MEAN" type="Numeric" unit="mV">12.9</value> <value name="POLARITY" type="MDC_IDC_ENUM_POLARITY">BI</value> </section> <section name="IMPEDANCE"> <value name="VALUE" type="Numeric" unit="Ohm">440</value> <value name="POLARITY" type="MDC_IDC_ENUM_POLARITY">BI</value> </section> </section> <section name="LEADHVCHNL"> <value name="DTM_END" type="DateTime">20100801T015536</value> <value name="IMPEDANCE" type="Numeric" unit="Ohm">52</value> <value name="MEASUREMENT_TYPE" type="MDC_IDC_ENUM_HVCHNL_MEASUREMENT_TYPE">LowVoltage</value> <value name="STATUS" type="MDC_IDC_ENUM_CHANNEL_STATUS">Null</value> </section> <section name="LEADHVCHNL"> <value name="DTM_END" type="DateTime">20100226T164630</value> <value name="IMPEDANCE" type="Numeric" unit="Ohm">28</value> <value name="MEASUREMENT_TYPE" type="MDC_IDC_ENUM_HVCHNL_MEASUREMENT_TYPE">Shock</value> <value name="STATUS" type="MDC_IDC_ENUM_CHANNEL_STATUS">CheckLead</value> </section> </section> <section name="SET"> <section name="MAGNET"> <value name="RESP" type="String">Tachyarrhythmia detection therapy temporarily deactivated</value> </section> <section name="LEADCHNL_RV"> <section name="SENSING"> <value name="POLARITY" type="MDC_IDC_ENUM_POLARITY">BI</value> <value name="ANODE_LOCATION_1" type="MDC_IDC_ENUM_ELECTRODE_LOCATION">RV</value> <value name="ANODE_ELECTRODE_1" type="MDC_IDC_ENUM_ELECTRODE_NAME">Tip</value> <value name="CATHODE_LOCATION_1" type="MDC_IDC_ENUM_ELECTRODE_LOCATION">RV</value> <value name="CATHODE_ELECTRODE_1" type="MDC_IDC_ENUM_ELECTRODE_NAME">Ring</value> <value name="ADAPTATION_MODE" type="MDC_IDC_ENUM_SENSING_ADAPTION_MODE">AdaptiveSensing</value> </section> <section name="PACING"> 112

Anexos

<value name="AMPLITUDE" type="Numeric" unit="V">4.0</value> <value name="PULSEWIDTH" type="Numeric" unit="ms">1.0</value> <value name="POLARITY" type="MDC_IDC_ENUM_POLARITY">BI</value> <value name="ANODE_LOCATION_1" type="MDC_IDC_ENUM_ELECTRODE_LOCATION">RV</value> <value name="ANODE_ELECTRODE_1" type="MDC_IDC_ENUM_ELECTRODE_NAME">Tip</value> <value name="CATHODE_LOCATION_1" type="MDC_IDC_ENUM_ELECTRODE_LOCATION">RV</value> <value name="CATHODE_ELECTRODE_1" type="MDC_IDC_ENUM_ELECTRODE_NAME">Ring</value> </section> </section> <section name="BRADY"> <value name="MODE" type="MDC_IDC_ENUM_BRADY_VENDOR_MODE">VVI</value> <value name="VENDOR_MODE" type="String">VVI</value> <value name="LOWRATE" type="Numeric" unit="{beats}/min">45</value> <value name="SENSOR_TYPE" type="String">Acceleration</value> </section> <section name="TACHYTHERAPY"> <value name="VSTAT" type="MDC_IDC_ENUM_THERAPY_STATUS">On</value> <value name="ASTAT" type="MDC_IDC_ENUM_THERAPY_STATUS">Off</value> </section> <section name="ZONE"> <value name="TYPE" type="MDC_IDC_ENUM_ZONE_TYPE">VF_Zone</value> <value name="VENDOR_TYPE" type="String">BIO-Zone_VF</value> <value name="STATUS" type="MDC_IDC_ENUM_ZONE_STATUS">Active</value> <value name="DETECTION_INTERVAL" type="Numeric" unit="ms">280</value> <value name="TYPE_ATP_1" type="MDC_IDC_ENUM_ATP_TYPE">Burst</value> <value name="NUM_ATP_SEQS_1" type="Numeric" unit="{seq}">1</value> <value name="SHOCK_ENERGY_3" type="Numeric" unit="J">30</value> <value name="SHOCK_ENERGY_1" type="Numeric" unit="J">30</value> <value name="SHOCK_ENERGY_2" type="Numeric" unit="J">30</value> <value name="NUM_SHOCKS_3" type="Numeric" unit="{shocks}">6</value> <value name="NUM_SHOCKS_1" type="Numeric" unit="{shocks}">1</value> <value name="NUM_SHOCKS_2" type="Numeric" unit="{shocks}">1</value> </section> <section name="ZONE"> <value name="TYPE" type="MDC_IDC_ENUM_ZONE_TYPE">VT_Zone</value> <value name="VENDOR_TYPE" type="String">BIO-Zone_VT2</value> <value name="STATUS" type="MDC_IDC_ENUM_ZONE_STATUS">Inactive</value> </section> <section name="ZONE"> <value name="TYPE" type="MDC_IDC_ENUM_ZONE_TYPE">VT_Zone</value> <value name="VENDOR_TYPE" type="String">BIO-Zone_VT1</value> <value name="STATUS" type="MDC_IDC_ENUM_ZONE_STATUS">Inactive</value> </section> </section> 113

Anexos

<section name="STAT"> <section name="HEART_RATE"> <value name="DTM_END" type="DateTime">20100801T015536</value> <value name="VENTRICULAR_MEAN" type="Numeric" unit="{beats}/min">67</value> </section> <section name="BRADY"> <value name="DTM_END" type="DateTime">20100801T015536</value> <value name="RV_PERCENT_PACED" type="Numeric" unit="%">10</value> </section> <section name="AT"> <value name="DTM_END" type="DateTime">20100801T015536</value> </section> <section name="CRT"> <value name="DTM_END" type="DateTime">20100801T015536</value> </section> <section name="TACHYTHERAPY"> <value name="SHOCKS_DELIVERED_TOTAL" type="Numeric" unit="{shocks}">0</value> <value name="SHOCKS_ABORTED_TOTAL" type="Numeric" unit="{shocks}">9</value> <value name="ATP_DELIVERED_TOTAL" type="Numeric" unit="{seq}">0</value> <value name="TOTAL_DTM_END" type="DateTime">20100801T015536</value> </section> <section name="EPISODE"> <value name="TYPE" type="MDC_IDC_ENUM_EPISODE_TYPE">Epis_VF</value> <value name="TYPE_INDUCED" type="MDC_IDC_ENUM_EPISODE_TYPE_INDUCED">NO</value> <value name="VENDOR_TYPE" type="MDC_IDC_ENUM_EPISODE_VENDOR_TYPE">BIO-Epis_VF</value> <value name="TOTAL_COUNT" type="Numeric">9</value> <value name="TOTAL_COUNT_DTM_END" type="Numeric">20100801T015536</value> </section> <section name="EPISODE"> <value name="TYPE" type="MDC_IDC_ENUM_EPISODE_TYPE">Epis_VT</value> <value name="TYPE_INDUCED" type="MDC_IDC_ENUM_EPISODE_TYPE_INDUCED">NO</value> <value name="VENDOR_TYPE" type="MDC_IDC_ENUM_EPISODE_VENDOR_TYPE">BIO-Epis_VT1</value> <value name="TOTAL_COUNT" type="Numeric">0</value> <value name="TOTAL_COUNT_DTM_END" type="Numeric">20100801T015536</value> </section> <section name="EPISODE"> <value name="TYPE" type="MDC_IDC_ENUM_EPISODE_TYPE">Epis_VT</value> <value name="TYPE_INDUCED" type="MDC_IDC_ENUM_EPISODE_TYPE_INDUCED">NO</value> 114

Anexos

<value name="VENDOR_TYPE" type="MDC_IDC_ENUM_EPISODE_VENDOR_TYPE">BIO-Epis_VT2</value> <value name="TOTAL_COUNT" type="Numeric">0</value> <value name="TOTAL_COUNT_DTM_END" type="Numeric">20100801T015536</value> </section> <section name="EPISODE"> <value name="TYPE" type="MDC_IDC_ENUM_EPISODE_TYPE">Epis_SVT</value> <value name="TYPE_INDUCED" type="MDC_IDC_ENUM_EPISODE_TYPE_INDUCED">NO</value> <value name="VENDOR_TYPE" type="MDC_IDC_ENUM_EPISODE_VENDOR_TYPE">BIO-Epis_SVT</value> <value name="TOTAL_COUNT" type="Numeric">0</value> <value name="TOTAL_COUNT_DTM_END" type="Numeric">20100801T015536</value> </section> </section> </section> <section name="ATTR"> <section name="PT"> <value name="ID" type="String">patICD</value> </section> </section> </section> <section name="BIO"> <section name="REQUEST"> <value name="DATE" type="Date Time">20100903T180102+0200</value> <value name="ID" type="String">53a4115b-f6e1-42c4-912e-df60524140da</value> <section name="HM"> <section name="STATUS"> <value name="COLOR" type="String">Red</value> <value name="COMMENT" type="String">some interrogation comment</value> <value name="TEXT" type="String">Status / Lead / S-Imp</value> </section> <section name="USER"> <value name="ID" type="String">berger_t1</value> <value name="NAME_FAMILY" type="String">Pillat</value> <value name="NAME_GIVEN" type="String">Berger</value> <value name="FAX" type="String">+123456</value> </section> <section name="PATIENT"> <value name="LINK" type="String">https://www.testsystemhomemonitoring.int/hmsc_guiWeb/qs/4028eed0200e597b01200f43d98627ba</value> <value name="CLINIC_ID" type="String">RPM</value> <value name="CLINIC_NAME" type="String">any clinic</value> </section> <section name="RECEIVER"> <value name="CLINIC_ID" type="String">RPM</value> <value name="CLINIC_NAME" type="String">any clinic</value> 115

Anexos

</section> </section> </section> </section> </dataset> </biotronik-ieee11073-export>

116

Anexos

Algoritmo LUA creado para el transformador del sistema integrador IGUANA
require("node") --require("hl7date") require("dateparse") require('node') require("db") require("stringutil") -- The main function is the first function called from Iguana. -- The Data argument will contain the message to be processed. function main(Data) -- Divide las secciones del archivo XML para porcesarlo local xml = parcea_xml2(Data) --Obtengo los campos del mensaje HL7 (ORU) definido en el archivo CVISOutbound.vmd local table_hl7 = table_hl7() --Se trae los datos de la base de datos para hacer el mapeo GLOBALMENTE table_db = query_db() --Se trae la tabla de IDC_normative_enumeration para efectuar el mapeo table_idc_normative = idc_normative() --Se trae la tabla de idc_enumerator_bio para efectuar el mapeo table_idc_bio_enumerator = idc_enumerator_bio() --Se trae la tabla de idc_expanded_term para efectuar el mapeo table_idc_expanded_term = idc_expanded_term() --Empieza el mapeo de los campos local resultado = mapeo_datos(xml,table_hl7) queue.push{data=resultado:S()} local p = MapData(Data) end function mapeo_datos(xml,table_hl7) -- Mapeo los datos de la cabecera MSH. MapMSH(xml[1],table_hl7.MSH ) -- Mapeo los datos del segemento PID MapPID(xml,table_hl7.PID) -- Mapeo los datos del segemento PIV MapPIV(xml,table_hl7.PV1) -- Mapeo los datos del segemento OBR MapOBR(xml,table_hl7.OBR) --Aqui envio toda la tabla HL 7 porque son varios OBX 117

Anexos

MapOBX(xml,table_hl7) --debug(table_hl7) return (table_hl7) --trace(table_hl7) end ---*** SECCION DE MAPEO DE LOS CAMPOS A MENSAJES HL7 ---*** -- Mapeo de la cabecera MSH function MapMSH(xml,MSH) MSH[3][1] = xml.creator MSH[4][1] = 'Biotronik' MSH[7] = os.date('%Y%m%d%H%M') MSH[9][1] = 'ORU' MSH[9][2] = 'R01' MSH[11][1] = 'D' MSH[12] = 2.6 MSH[5][1] = xml.dataset:child("section", 2).section.section:child("section", 4).value[3] --Genero un codigo de identificacion unico del mensaje MSH[10] = util.guid(128) MSH[6][1] = xml.dataset:child("section", 2).section.section:child("section", 4):child("value", 2)[3] return MSH end --- Mapeo de los campos del PID function MapPID (xml,PID) -- Busca si existe un id de paciente para un modelo y serial dado --Aqui en el PID los datos del pacients deben de ser sacados por --programa gestor de marcapasos, pero en este caso se sacaron --de la base de datos simulando esta funcion. local paciente_id = busca_paciente_id(xml) local paciente_datos = busca_pacientes_datos(paciente_id) PID[3][1] = convierte_mayusculas(paciente_id[1].idmarcapasos) -- Obtengo la empresa que hizo el marcapasos PID[3][4][1] =xml[2].section.section.section:child("value", 4)[3] --Siempre se pone esta U segun la defincion del IHE PID[3][5] = "U" PID[5][1] = convierte_mayusculas(paciente_datos[1].surname1) PID[5][2] = convierte_mayusculas(paciente_datos[1].first_name) PID[6][1] = convierte_mayusculas(paciente_datos[1].surname2) --Fecha de cumpleaños PID[7] = os.date('%Y%m%d%H%M', dateparse.parse(paciente_datos[1].birth_date:S())) 118

Anexos

-- Asigno si es mascuilino o femenino el paciente if tostring(paciente_datos[1].sex) == "V" then PID[8] = 'M' else PID[8] = 'F' end --Direccion del Paciente PID[11][1] = paciente_datos[1].address PID[11][3] = "Valencia" PID[11][6] = "España" return PID end -- Seccion de mapeo de PIV -- Estos datos son inventados ya que estamos realizando pruebas y si queremos que -- funcione realmente se deben de obtener del sistema gestor de marcapasos. function MapPIV(xml,PIV) PIV[1] =1 PIV[2] = "R" PIV[7][1] = "ASANCHEZ" PIV[7][2] = "SANCHEZ" PIV[7][3] = "CHAPATIN" PIV[7][6] = "DR." --Identifiador de mensaje PIV[19][1] = util.guid(128) return PIV end function MapOBR(xml,OBR) OBR[1][1]= 1 --Identificador de cabecera OBR OBR[1][3][1] = util.guid(128) -- Se obtuvo desde una ubicacion Remote OBR[1][4][1] = xml[5]:child("value", 2)[3] --FEcha de inicio viene el archivo xml OBR[1][7] = string.gsub (tostring((xml[10].section.value[3])),"T","") -- OBR[1][7] = os.date('%Y%m%d%H%M%S', dateparse.parse(xml[10].section.value[3])) OBR[1][8] = string.gsub (tostring((xml[10].section.value[3])),"T","") --Resultados finales ver tabla 3.Y.4.1.2-8 OBR[1][25] = "F" return OBR end

119

Anexos

--Seccion de registros OBX function MapOBX(xml,OBX) agrega_obx(xml,OBX,table_db) return OBX end ---***************** ---***************** function agrega_obx(xml,OBX,table_db) --Esta variable la puse para poner el archivo xml visible --para todas las funciones xml_bio = xml local dato = tostring(xml[2].section.section.name) local valor = xml[2].section.section:childCount("section") -- Veo que la cabecear sea IDC if dato == 'IDC' then --obtendo las datos de las secciones IDC local datos = xml[2].section.section mapea_etiquetas(xml[2].section.section,valor,OBX) end return OBX end

function mapea_etiquetas(xml,valor,OBX) contador = 0 for i=1,valor do local dato = tostring(xml:child("section", i).name) --- MAPO DEL SEGMENTO DE MDC_IDC_PG if dato == "PG" then -- local variable = xml.section:childCount("value") MDC_IDC_PG = "MDC_IDC".."_"..dato print(MDC_IDC_PG) local variable = xml:child("section", i):childCount("section") local variable_2 = xml:child("section", i) if xml:child("section", i):childIndex("value") then local variable = xml:child("section", i):childCount("value") revisa_nodo_final(variable,MDC_IDC_PG,OBX,variable_2) else revisa_nodo_section(variable,variable_2,MDC_IDC_PG,dato,xml,OBX) end 120

Anexos

--- MAPEO DEL SEGMENTO DE MDC_IDC_SESS FUNCIONA MUY BIEN ESTE NODO elseif dato == "SESS" then MDC_IDC_SESS = "MDC_IDC".."_"..dato print(MDC_IDC_SESS) local variable = xml:child("section", i):childCount("section") local variable_2 = xml:child("section", i) -- si es el ultimo nodo y contiene la eqtiqueta value es el nodo final if xml:child("section", i):childIndex("value") then local variable = xml:child("section", i):childCount("value") local variable_2 = xml:child("section", i) revisa_nodo_final(variable,MDC_IDC_SESS,OBX,variable_2) else revisa_nodo_section(variable,variable_2,MDC_IDC_MSMT,dato,xml,OBX) end --Aqui no es ultimo nodo y tendremos que hacer una funcion parasaber si lo es elseif dato == "MSMT" then MDC_IDC_MSMT = "MDC_IDC".."_"..dato print(MDC_IDC_MSMT) local variable = xml:child("section", i):childCount("section") local variable_2 = xml:child("section", i) if xml:child("section", i):childIndex("value") then local variable = xml:child("section", i):childCount("value") revisa_nodo_final(variable,MDC_IDC_SESS,OBX,variable_2) else revisa_nodo_section(variable,variable_2,MDC_IDC_MSMT,dato,xml,OBX) end elseif dato == "SET" then MDC_IDC_SET = "MDC_IDC".."_"..dato print(MDC_IDC_SET) local variable = xml:child("section", i):childCount("section") local variable_2 = xml:child("section", i) -- si es el ultimo nodo y contiene la eqtiqueta value es el nodo final if xml:child("section", i):childIndex("value") then local variable = xml:child("section", i):childCount("value") revisa_nodo_final(variable,MDC_IDC_SET,dato,xml,OBX,variable_2) else revisa_nodo_section(variable,variable_2,MDC_IDC_SET,dato,xml,OBX) end elseif dato == "STAT" then MDC_IDC_STAT = "MDC_IDC".."_"..dato print(MDC_IDC_STAT) 121

Anexos

local variable_2 = xml:child("section", i) local variable = xml:child("section", i):childCount("section") -- si es el ultimo nodo y contiene la eqtiqueta value es el nodo final if xml:child("section", i):childIndex("value") then local variable = xml:child("section", i):childCount("value") revisa_nodo_final(variable,MDC_IDC_STAT,dato,xml,OBX,variable_2) else revisa_nodo_section(variable,variable_2,MDC_IDC_STAT,dato,xml,OBX) end end end end ----Esta funcion nos toma los valores de los nodos finales (VALUE) function revisa_nodo_final(variable,MDC_IDC_PG,OBX,variable_2 ) local valor = "" local section = "" for i=1,variable do -- Se hizo para saber si tenia unidadees o no el campo if variable_2:child("value",i).unit then valor = variable_2:child("value",i)[4] print(variable_2:child("value",i)[4]) else valor = variable_2:child("value",i)[3] end section = variable_2:child("value", i) agrega_OBX(variable_2:child("value",i).name,valor,MDC_IDC_PG,OBX,section) print(variable_2:child("value",i).name) print(variable_2:child("value",i).type) print(variable_2:child("value",i).unit) print(variable_2:child("value",i)[3]) end end function revisa_nodo_section(valor,xml,MDC_IDC_MSMT,dato,t,OBX) local MSM_IDC = MDC_IDC_MSMT for i=1,valor do -- si existen mas secciones de section if xml:child("section", i):childIndex("section") then print( xml:child("section", i):childCount("section")) 122

Anexos

print (xml:child("section", i).name) for p=1, xml:child("section", i):childCount("section") do print (xml:child("section", i):child("section", p).name ) print(xml:child("section", i):child("section", p):childCount("value")) MDC_IDC_MSMT = MDC_IDC_MSMT MDC_IDC = MDC_IDC_MSMT ..'_'.. xml:child("section", i).name..'_'..xml:child("section", i):child("section", p).name print ( MDC_IDC) revisa_nodo_final(xml:child("section", i):child("section", p):childCount("value"),MDC_IDC,OBX,xml:child("section", i):child("section", p) ) end --- lo hago para ver secciones de value dentro de las secciones de sections if xml:child("section", i):childIndex("value") then MDC_IDC_MSMT = MDC_IDC_MSMT print (xml:child("section", i):childCount("value") ) MDC_IDC = MDC_IDC_MSMT ..'_'.. xml:child("section", i).name revisa_nodo_final(xml:child("section", i):childCount("value") ,MDC_IDC,OBX,xml:child("section", i) ) print (MDC_IDC) end -- AQUI EL NODO YA NO TIENE MAS SECTIONES Y SE LLAMA A LA FUNCION PARA AGREGAR EL XML else MDC_IDC_MSMT = MDC_IDC_MSMT print (xml:child("section", i):childCount("value") ) MDC_IDC = MDC_IDC_MSMT ..'_'.. xml:child("section", i).name revisa_nodo_final(xml:child("section", i):childCount("value"),MDC_IDC,OBX,xml:child("section", i) ) end end end function agrega_OBX(dato,valor,MDC_IDC_PG,OBX,section) local nomenclatura = MDC_IDC_PG.."_"..dato print(nomenclatura) -- #table_idc_expanded_term for p=1,#table_idc_expanded_term do if tostring(table_idc_expanded_term[p].Reference_ID) == tostring(nomenclatura) then 123

Anexos

print(nomenclatura) contador = contador + 1 OBX.OBX[contador][1] = contador --El valor de evento PG,SESS ETC.. OBX.OBX[contador][3][2] = tostring(nomenclatura) --Seguna la IHE se ponde esta terminologia OBX.OBX[contador][3][3] = 'MDC' -- Rutina para mapear los tipos de datos si devuelve true queire decir -- que si eoncontro el codigo en la tablas si es false pongo el codigo de esta tabla if mapea_tipos(section,OBX,nomenclatura) then else OBX.OBX[contador][3][1] = tostring(table_idc_expanded_term[p].Code) end print(tostring(OBX.OBX[contador][2])) OBX.OBX[contador][5][1] = mapea_valor(section[3],OBX.OBX[contador][2]) if section.unit then valor = section.unit OBX.OBX[contador][6][1] = section.unit if tostring(section.unit) == '%' then else OBX.OBX[contador][6][2] = 'UCUM' end print(section.unit) OBX.OBX[contador][5][1] = mapea_valor(section[4],OBX.OBX[contador][2]) else OBX.OBX[contador][5][1] = mapea_valor(section[3],OBX.OBX[contador][2]) end end

OBX.OBX[contador][11] = 'F' OBX.OBX[contador][14] = string.gsub (tostring((xml_bio[10].section.value[3])),"T","") --Mapea las fechas porque tiene una T segun el tipo de datos -- OBX.OBX[contador][5][1] = mapea_valor(valor,OBX.OBX[contador][2]) end --Se trae la tabla de IDC_normative_enumeration para efectuar el mapeo -- table_idc_normative = idc_normative() --Se trae la tabla de idc_enumerator_bio para efectuar el mapeo -- table_idc_bio_enumerator = idc_enumerator_bio() --Se trae la tabla de idc_expanded_term para efectuar el mapeo 124

Anexos

--

table_idc_expanded_term = idc_expanded_term()

--[[ for i=1,#table_db do if tostring(table_db[i].reference_id) == nomenclatura then --a qui es necesario mover el primer valor para cambiar el numero de registros de OBX contador = contador + 1 OBX.OBX[contador][1] = contador OBX.OBX[contador][3][1] = tostring(table_db[i].code) OBX.OBX[contador][2] = table_db[i].metric_type_hl7 OBX.OBX[contador][3][2] = nomenclatura --Seguna la IHE se ponde esta terminologia OBX.OBX[contador][3][3] = 'MDC' --Se hace para mapear los tipos de datos OBX.OBX[contador][5][1] = mapea_valor(valor,i) OBX.OBX[contador][6][1] = table_db[i].units -- HACe para ver si el valor que se obtuvo esta vacio o no if tostring(table_db[i].units) == 'NULL' then else print('UCUM') OBX.OBX[contador][6][2] = 'UCUM' end OBX.OBX[contador][11] = 'F' OBX.OBX[contador][14] = string.gsub (tostring((xml_bio[10].section.value[3])),"T","") print(dato) end end ]] end function mapea_tipos(section,OBX,nomenclatura) -- Se hizo para saber si tenia unidadees o no el campo if section.type then --OBX.OBX[contador][2] = 'CWE' if tostring(section.type) == 'String' then --String OBX.OBX[contador][2] = 'ST' end if tostring(section.type) == 'DateTime' then --Date Time OBX.OBX[contador][2] = 'DTM' end if tostring(section.type) == 'Structured Numeric' then --Structured Numeric OBX.OBX[contador][2] = 'SN' end if tostring(section.type) == 'Numeric' then --NM 125

Anexos

OBX.OBX[contador][2] = 'NM' end if mapea_enum(section.type,OBX, section,nomenclatura) then OBX.OBX[contador][2] = 'CWE' return true end end end function mapea_enum(section,OBX,secciones,nomenclatura) valor = section section = string.find(tostring(section), 'ENUM') vendor = string.find(tostring(section), 'VENDOR') if section then --Busco el codigo relacionado con el tipo de enumeartion for l=1, #table_idc_normative do if tostring(table_idc_normative[l].enumeration_code) == tostring(secciones[3]) then -- Lo hize porque no existia el valor MDC_IDC_ENUM_BRADY_VENDOR_MODE en las tablas -- asi que le puse el identificador MDC_IDC_ENUM_BRADY_MODE if tostring(valor) == 'MDC_IDC_ENUM_BRADY_VENDOR_MODE' then valor = 'MDC_IDC_ENUM_BRADY_MODE' end if tostring(table_idc_normative[l].reference_id) == tostring(valor) then print(table_idc_normative[l].reference_id) OBX.OBX[contador][3][1] = table_idc_normative[l].code end end if tostring(table_idc_bio_enumerator[l].enumeration_code) == tostring(secciones[3]) then -- Lo hize porque no existia el valor MDC_IDC_ENUM_BRADY_VENDOR_MODE en las tablas -- asi que le puse el identificador MDC_IDC_ENUM_BRADY_MODE if tostring(valor) == 'MDC_IDC_ENUM_BRADY_VENDOR_MODE' then valor = 'MDC_IDC_ENUM_BRADY_MODE' end if tostring(table_idc_bio_enumerator[l].enumerator) == tostring(valor) then print(table_idc_bio_enumerator[l].code_mfg) OBX.OBX[contador][3][1] = table_idc_bio_enumerator[l].code end end

end return section end end 126

Anexos

function convierte_mayusculas(dato) return string.upper(tostring(dato)) end function busca_pacientes_datos(id) Results = db.query{api=db.MY_SQL,name='openclinic', user='root', password='admin', sql='SELECT * FROM patient_tbl WHERE nif = "'.. id[1].idpatient .. '"', live=true} return Results end function busca_paciente_id(id) --obtengo el modelo y serial del dispositivo para referenciarlos con la tabla `id_marca_patient_tbl` y obtener el id del paciente local modelo = id[2].section.section.section:child("value", 2)[3] local serial = id[2].section.section.section:child("value", 3)[3] -- El perfil de IHE nos dice que este sera el identificador del marcapasos para obtener el id del paciente. local id_marcapasos = "model:"..modelo .."/".."serial:".. serial Results = db.query{api=db.MY_SQL,name='openclinic', user='root', password='admin', sql='SELECT idpatient, idmarcapasos FROM id_marca_patient_tbl WHERE idmarcapasos = "'.. id_marcapasos .. '"', live=true} return Results end --*** Traigo todos los datos de los codigos iso 11703 de la base de datos para hacer el mapeo. function query_db() Results = db.query{api=db.MY_SQL,name='openclinic', user='root', password='admin', sql='SELECT reference_id, code,display_name,definition,units,reporter_field,metric_type_hl7 FROM idc_mdc_nomen', live=true} return Results end --*** Traigo todos los datos de la tabla idc_normative_enumerations para hacer el mapeo de los campos. function idc_normative() Results = db.query{api=db.MY_SQL,name='openclinic', user='root', password='admin', sql='SELECT reference_id, enumeration_code,code FROM idc_normative_enumerations', live=true} return Results end --*** Traigo todos los datos de la tabla idc_enumerator_bio para hacer el mapeo de los campos. function idc_enumerator_bio() 127

Anexos

Results = db.query{api=db.MY_SQL,name='openclinic', user='root', password='admin', sql='SELECT code_mfg,enumerator,enumeration_code,display_name,code FROM idc_enumerator_bio', live=true} return Results end --*** Traigo todos los datos de la tabla idc_enumerator_bio para hacer el mapeo de los campos. function idc_expanded_term() Results = db.query{api=db.MY_SQL,name='openclinic', user='root', password='admin', sql='SELECT Reference_ID,Code,Enumeration FROM idc_expanded_term', live=true} return Results end --Obtengo la estructura del mensaje ORu del archivo function table_hl7() local Msg = hl7.message{vmd='CVISOutbound.vmd', name='ORU'} return Msg end ---Seccion para parsear el archivo function parcea_xml2(Data) local X = xml.parse{data=Data} local encabezado = X["biotronik-ieee11073-export"] --- Aquie obtenemos las ramificaciones del XML -- seccion dataset local dataset = X["biotronik-ieee11073-export"]:child('dataset') print(dataset) local var = X["biotronik-ieee11073-export"].dataset.section --varibales de tipo IDC local MDC_IDC_PG_TYPE_PG = var.section.section local MDC_IDC_PG_TYPE_SESS = var.section:child("section", 2) local MDC_IDC_PG_TYPE_MSMT = var.section:child("section", 3) local MDC_IDC_PG_TYPE_SET = var.section:child("section", 4) local MDC_IDC_PG_TYPE_STAT = var.section:child("section", 5) --Variables de tipo ATTR local MDC_ATTR_PT = var:child("section", 2) ---- Variables de BIO local BIO = X["biotronik-ieee11073-export"].dataset:child("section", 2) xml_secciones ={encabezado,dataset,var,MDC_IDC_PG_TYPE_PG,MDC_IDC_PG_TYPE_SESS,MDC_IDC_PG_TYPE_M SMT,MDC_IDC_PG_TYPE_SET,MDC_IDC_PG_TYPE_STAT,MDC_ATTR_PT,BIO } 128

Anexos

return xml_secciones end function debug(M) end

function mapea_valor(valor,i) -- local tabla = tostring(table_db[i].metric_type_hl7) -- Parar procesar los datos de FECHA if tostring(i) == 'DTM' then valor = string.gsub (tostring(valor),"T","") end return valor end -- revisa si hay un nodo con un nombre dado function node.childIndex(Node, Name) for i=1, #Node do if Node[i]:nodeName() == Name then print (Node[i]:nodeName()) return i end end return nil

129

Anexos

Mensaje final generado por el actor DOR.
MSH|^~\&|BioHMSC|Biotronik|RPM|any clinic|201203170127||ORU^R01|6FDA634FAB035E97540F3A12E97784B7|D|2.6| PID|||MODEL:LUMAX 300 VRT/SERIAL:110011^^^BIO^U||CORTES^ALVARO|MANICA|198406020000|M|||Pintordevilar4^^Valencia^^^España| PV1|1|R|||||ASANCHEZ^SANCHEZ^CHAPATIN^^^DR.||||||||||||6FDA634FBD03A34E8542750BB22F1B10| OBR|1||6FDA634FBD03D5ED50656D1EC4A98B7B|Remote|||20100903180102+0200|20100903180102+0200||||| ||||||||||||F| OBX|1|CWE|753666^MDC_IDC_PG_TYPE^MDC||ICD||||||F|||20100903180102+0200| OBX|2|ST|720898^MDC_IDC_PG_MODEL^MDC||Lumax 300 VR-T||||||F|||20100903180102+0200| OBX|3|ST|720899^MDC_IDC_PG_SERIAL^MDC||110011||||||F|||20100903180102+0200| OBX|4|CWE|753731^MDC_IDC_PG_MFG^MDC||BIO||||||F|||20100903180102+0200| OBX|5|DTM|720901^MDC_IDC_PG_IMPLANT_DT^MDC||20071103113124||||||F|||20100903180102+0200| OBX|6|DTM|721025^MDC_IDC_SESS_DTM^MDC||20101001013954+0200||||||F|||20100903180102+0200| OBX|7|CWE|754051^MDC_IDC_SESS_TYPE^MDC||Remote||||||F|||20100903180102+0200| OBX|8|CWE|755202^MDC_IDC_SESS_REPROGRAMMED^MDC||NO||||||F|||20100903180102+0200| OBX|9|DTM|721028^MDC_IDC_SESS_DTM_PREVIOUS^MDC||20100420115026||||||F|||20100903180102+0200| OBX|10|CWE|754050^MDC_IDC_SESS_TYPE_PREVIOUS^MDC||InClinic||||||F|||20100903180102+0200| OBX|11|ST|721031^MDC_IDC_SESS_CLINICIAN_NAME^MDC||Thomas Berger||||||F|||20100903180102+0200| OBX|12|ST|721032^MDC_IDC_SESS_CLINICIAN_CONTACT_INFORMATION^MDC||Fax: +123456||||||F|||20100903180102+0200| OBX|13|ST|721033^MDC_IDC_SESS_CLINIC_NAME^MDC||any clinic||||||F|||20100903180102+0200| OBX|14|DTM|721216^MDC_IDC_MSMT_BATTERY_DTM^MDC||20100801015536||||||F|||20100903180102+0200 | OBX|15|CWE|754116^MDC_IDC_MSMT_BATTERY_STATUS^MDC||MOS||||||F|||20100903180102+0200| OBX|16|NM|721536^MDC_IDC_MSMT_BATTERY_REMAINING_PERCENTAGE^MDC||68.0|%|||||F|||201009031 80102+0200| OBX|17|DTM|721216^MDC_IDC_MSMT_BATTERY_DTM^MDC||20100801000000||||||F|||20100903180102+0200 | OBX|18|NM|721344^MDC_IDC_MSMT_BATTERY_VOLTAGE^MDC||3.10|V^UCUM|||||F|||20100903180102+020 0| OBX|19|DTM|721664^MDC_IDC_MSMT_CAP_CHARGE_DTM^MDC||20100527000013||||||F|||20100903180102+ 0200| OBX|20|NM|721728^MDC_IDC_MSMT_CAP_CHARGE_TIME^MDC||8.5|s^UCUM|||||F|||20100903180102+0200| OBX|21|NM|721792^MDC_IDC_MSMT_CAP_CHARGE_ENERGY^MDC||30|J^UCUM|||||F|||20100903180102+02 00| OBX|22|CWE|754178^MDC_IDC_MSMT_CAP_CHARGE_TYPE^MDC||Reformation||||||F|||20100903180102+020 0| OBX|23|NM|722054^MDC_IDC_MSMT_LEADCHNL_RV_SENSING_INTR_AMPL_MIN^MDC||12.9|mV^UCUM||||| F|||20100903180102+0200| OBX|24|NM|722055^MDC_IDC_MSMT_LEADCHNL_RV_SENSING_INTR_AMPL_MEAN^MDC||12.9|mV^UCUM| ||||F|||20100903180102+0200| OBX|25|CWE|754306^MDC_IDC_MSMT_LEADCHNL_RV_SENSING_POLARITY^MDC||BI||||||F|||201009031801 02+0200| OBX|26|NM|722433^MDC_IDC_MSMT_LEADCHNL_RV_IMPEDANCE_VALUE^MDC||440|Ohm^UCUM|||||F|||20 100903180102+0200| OBX|27|CWE|754306^MDC_IDC_MSMT_LEADCHNL_RV_IMPEDANCE_POLARITY^MDC||BI||||||F|||201009031 80102+0200| OBX|28|DTM|721926^MDC_IDC_MSMT_LEADCHNL_RV_DTM_END^MDC||20100801015536||||||F|||201009031 80102+0200| OBX|29|CWE|754242^MDC_IDC_MSMT_LEADCHNL_RV_LEAD_CHANNEL_STATUS^MDC||Null||||||F|||201009 03180102+0200| OBX|30|DTM|722562^MDC_IDC_MSMT_LEADHVCHNL_DTM_END^MDC||20100801015536||||||F|||2010090318 0102+0200| OBX|31|NM|722624^MDC_IDC_MSMT_LEADHVCHNL_IMPEDANCE^MDC||52|Ohm^UCUM|||||F|||20100903180 102+0200| OBX|32|CWE|754433^MDC_IDC_MSMT_LEADHVCHNL_MEASUREMENT_TYPE^MDC||LowVoltage||||||F|||2010 0903180102+0200| OBX|33|CWE|754242^MDC_IDC_MSMT_LEADHVCHNL_STATUS^MDC||Null||||||F|||20100903180102+0200|

130

Anexos

OBX|34|DTM|722562^MDC_IDC_MSMT_LEADHVCHNL_DTM_END^MDC||20100226164630||||||F|||2010090318 0102+0200| OBX|35|NM|722624^MDC_IDC_MSMT_LEADHVCHNL_IMPEDANCE^MDC||28|Ohm^UCUM|||||F|||20100903180 102+0200| OBX|36|CWE|754434^MDC_IDC_MSMT_LEADHVCHNL_MEASUREMENT_TYPE^MDC||Shock||||||F|||20100903 180102+0200| OBX|37|CWE|754241^MDC_IDC_MSMT_LEADHVCHNL_STATUS^MDC||CheckLead||||||F|||20100903180102+0 200| OBX|38|ST|729472^MDC_IDC_SET_MAGNET_RESP^MDC||Tachyarrhythmia detection therapy temporarily deactivated||||||F|||20100903180102+0200| OBX|39|CWE|754306^MDC_IDC_SET_LEADCHNL_RV_SENSING_POLARITY^MDC||BI||||||F|||20100903180102 +0200| OBX|40|CWE|754498^MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_LOCATION_1^MDC||RV||||||F|||201 00903180102+0200| OBX|41|CWE|754561^MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_ELECTRODE_1^MDC||Tip||||||F|||2 0100903180102+0200| OBX|42|CWE|754498^MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_LOCATION_1^MDC||RV||||||F|||2 0100903180102+0200| OBX|43|CWE|754562^MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_ELECTRODE_1^MDC||Ring|||||| F|||20100903180102+0200| OBX|44|CWE|754625^MDC_IDC_SET_LEADCHNL_RV_SENSING_ADAPTATION_MODE^MDC||AdaptiveSensi ng||||||F|||20100903180102+0200| OBX|45|NM|729985^MDC_IDC_SET_LEADCHNL_RV_PACING_AMPLITUDE^MDC||4.0|V^UCUM|||||F|||2010090 3180102+0200| OBX|46|NM|730049^MDC_IDC_SET_LEADCHNL_RV_PACING_PULSEWIDTH^MDC||1.0|ms^UCUM|||||F|||2010 0903180102+0200| OBX|47|CWE|754306^MDC_IDC_SET_LEADCHNL_RV_PACING_POLARITY^MDC||BI||||||F|||20100903180102+ 0200| OBX|48|CWE|754498^MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_LOCATION_1^MDC||RV||||||F|||2010 0903180102+0200| OBX|49|CWE|754561^MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_ELECTRODE_1^MDC||Tip||||||F|||201 00903180102+0200| OBX|50|CWE|754498^MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_LOCATION_1^MDC||RV||||||F|||20 100903180102+0200| OBX|51|CWE|754562^MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_ELECTRODE_1^MDC||Ring||||||F|| |20100903180102+0200| OBX|52|CWE|754773^MDC_IDC_SET_BRADY_MODE^MDC||VVI||||||F|||20100903180102+0200| OBX|53|ST|730816^MDC_IDC_SET_BRADY_VENDOR_MODE^MDC||VVI||||||F|||20100903180102+0200| OBX|54|NM|730880^MDC_IDC_SET_BRADY_LOWRATE^MDC||45|{beats}/min^UCUM|||||F|||20100903180102+0 200| OBX|55|ST|731072^MDC_IDC_SET_BRADY_SENSOR_TYPE^MDC||Acceleration||||||F|||20100903180102+0200| OBX|56|CWE|754817^MDC_IDC_SET_TACHYTHERAPY_VSTAT^MDC||On||||||F|||20100903180102+0200| OBX|57|CWE|754818^MDC_IDC_SET_TACHYTHERAPY_ASTAT^MDC||Off||||||F|||20100903180102+0200| OBX|58|CWE|754945^MDC_IDC_SET_ZONE_TYPE^MDC||VF_Zone||||||F|||20100903180102+0200| OBX|59|ST|731712^MDC_IDC_SET_ZONE_VENDOR_TYPE^MDC||BIOZone_VF||||||F|||20100903180102+0200| OBX|60|CWE|755009^MDC_IDC_SET_ZONE_STATUS^MDC||Active||||||F|||20100903180102+0200| OBX|61|NM|731840^MDC_IDC_SET_ZONE_DETECTION_INTERVAL^MDC||280|ms^UCUM|||||F|||20100903180 102+0200| OBX|62|CWE|755073^MDC_IDC_SET_ZONE_TYPE_ATP_1^MDC||Burst||||||F|||20100903180102+0200| OBX|63|NM|732161^MDC_IDC_SET_ZONE_NUM_ATP_SEQS_1^MDC||1|{seq}^UCUM|||||F|||20100903180102+ 0200| OBX|64|NM|732227^MDC_IDC_SET_ZONE_SHOCK_ENERGY_3^MDC||30|J^UCUM|||||F|||20100903180102+02 00| OBX|65|NM|732225^MDC_IDC_SET_ZONE_SHOCK_ENERGY_1^MDC||30|J^UCUM|||||F|||20100903180102+02 00| OBX|66|NM|732226^MDC_IDC_SET_ZONE_SHOCK_ENERGY_2^MDC||30|J^UCUM|||||F|||20100903180102+02 00| OBX|67|NM|732291^MDC_IDC_SET_ZONE_NUM_SHOCKS_3^MDC||6|{shocks}^UCUM|||||F|||20100903180102 +0200|

131

Anexos

OBX|68|NM|732289^MDC_IDC_SET_ZONE_NUM_SHOCKS_1^MDC||1|{shocks}^UCUM|||||F|||20100903180102 +0200| OBX|69|NM|732290^MDC_IDC_SET_ZONE_NUM_SHOCKS_2^MDC||1|{shocks}^UCUM|||||F|||20100903180102 +0200| OBX|70|CWE|754946^MDC_IDC_SET_ZONE_TYPE^MDC||VT_Zone||||||F|||20100903180102+0200| OBX|71|ST|731712^MDC_IDC_SET_ZONE_VENDOR_TYPE^MDC||BIOZone_VT2||||||F|||20100903180102+0200| OBX|72|CWE|755010^MDC_IDC_SET_ZONE_STATUS^MDC||Inactive||||||F|||20100903180102+0200| OBX|73|CWE|754946^MDC_IDC_SET_ZONE_TYPE^MDC||VT_Zone||||||F|||20100903180102+0200| OBX|74|ST|731712^MDC_IDC_SET_ZONE_VENDOR_TYPE^MDC||BIOZone_VT1||||||F|||20100903180102+0200| OBX|75|CWE|755010^MDC_IDC_SET_ZONE_STATUS^MDC||Inactive||||||F|||20100903180102+0200| OBX|76|DTM|737618^MDC_IDC_STAT_HEART_RATE_DTM_END^MDC||20100801015536||||||F|||20100903180 102+0200| OBX|77|NM|737651^MDC_IDC_STAT_HEART_RATE_VENTRICULAR_MEAN^MDC||67|{beats}/min^UCUM|||||F| ||20100903180102+0200| OBX|78|DTM|737506^MDC_IDC_STAT_BRADY_DTM_END^MDC||20100801015536||||||F|||20100903180102+02 00| OBX|79|NM|737536^MDC_IDC_STAT_BRADY_RV_PERCENT_PACED^MDC||10|%|||||F|||20100903180102+020 0| OBX|80|DTM|737666^MDC_IDC_STAT_AT_DTM_END^MDC||20100801015536||||||F|||20100903180102+0200| OBX|81|DTM|737778^MDC_IDC_STAT_CRT_DTM_END^MDC||20100801015536||||||F|||20100903180102+0200| OBX|82|NM|737840^MDC_IDC_STAT_TACHYTHERAPY_SHOCKS_DELIVERED_TOTAL^MDC||0|{shocks}^UC UM|||||F|||20100903180102+0200 OBX|83|NM|737872^MDC_IDC_STAT_TACHYTHERAPY_SHOCKS_ABORTED_TOTAL^MDC||9|{shocks}^UCU M|||||F|||20100903180102+0200| OBX|84|NM|737904^MDC_IDC_STAT_TACHYTHERAPY_ATP_DELIVERED_TOTAL^MDC||0|{seq}^UCUM|||||F|| |20100903180102+0200| OBX|85|DTM|737922^MDC_IDC_STAT_TACHYTHERAPY_TOTAL_DTM_END^MDC||20100801015536||||||F|||20 100903180102+0200| OBX|86|CWE|754881^MDC_IDC_STAT_EPISODE_TYPE^MDC||Epis_VF||||||F|||20100903180102+0200| OBX|87|CWE|755330^MDC_IDC_STAT_EPISODE_TYPE_INDUCED^MDC||NO||||||F|||20100903180102+0200| OBX|88|CWE|770049^MDC_IDC_STAT_EPISODE_VENDOR_TYPE^MDC||BIOEpis_VF||||||F|||20100903180102+0200| OBX|89|NM|738032^MDC_IDC_STAT_EPISODE_TOTAL_COUNT^MDC||9||||||F|||20100903180102+0200| OBX|90|NM|738050^MDC_IDC_STAT_EPISODE_TOTAL_COUNT_DTM_END^MDC||20100801T015536||||||F|||2 0100903180102+0200| OBX|91|CWE|754882^MDC_IDC_STAT_EPISODE_TYPE^MDC||Epis_VT||||||F|||20100903180102+0200| OBX|92|CWE|755330^MDC_IDC_STAT_EPISODE_TYPE_INDUCED^MDC||NO||||||F|||20100903180102+0200| OBX|93|CWE|770051^MDC_IDC_STAT_EPISODE_VENDOR_TYPE^MDC||BIOEpis_VT1||||||F|||20100903180102+0200| OBX|94|NM|738032^MDC_IDC_STAT_EPISODE_TOTAL_COUNT^MDC||0||||||F|||20100903180102+0200| OBX|95|NM|738050^MDC_IDC_STAT_EPISODE_TOTAL_COUNT_DTM_END^MDC||20100801T015536||||||F|||2 0100903180102+0200| OBX|96|CWE|754882^MDC_IDC_STAT_EPISODE_TYPE^MDC||Epis_VT||||||F|||20100903180102+0200| OBX|97|CWE|755330^MDC_IDC_STAT_EPISODE_TYPE_INDUCED^MDC||NO||||||F|||20100903180102+0200| OBX|98|CWE|770052^MDC_IDC_STAT_EPISODE_VENDOR_TYPE^MDC||BIOEpis_VT2||||||F|||20100903180102+0200| OBX|99|NM|738032^MDC_IDC_STAT_EPISODE_TOTAL_COUNT^MDC||0||||||F|||20100903180102+0200| OBX|100|NM|738050^MDC_IDC_STAT_EPISODE_TOTAL_COUNT_DTM_END^MDC||20100801T015536||||||F||| 20100903180102+0200| OBX|101|CWE|754884^MDC_IDC_STAT_EPISODE_TYPE^MDC||Epis_SVT||||||F|||20100903180102+0200| OBX|102|CWE|755330^MDC_IDC_STAT_EPISODE_TYPE_INDUCED^MDC||NO||||||F|||20100903180102+0200| OBX|103|CWE|770053^MDC_IDC_STAT_EPISODE_VENDOR_TYPE^MDC||BIOEpis_SVT||||||F|||20100903180102+0200| OBX|104|NM|738032^MDC_IDC_STAT_EPISODE_TOTAL_COUNT^MDC||0||||||F|||20100903180102+0200| OBX|105|NM|738050^MDC_IDC_STAT_EPISODE_TOTAL_COUNT_DTM_END^MDC||20100801T015536||||||F||| 20100903180102+0200|

132

Lista de Figuras

LISTA DE FIGURAS
Figura 1.1 Anatomia del Corazón ............................................................................................................................. 3 Figura 1.2. Sistema eléctrico del corazón ........................................................................................................... 4 Figura 1.3. Componentes de un marcapasos genérico................................................................................. 5 Figura 1.4. Figura de un marcapasos implantado ............................................................................................ 6 Figura 1.5. Marcapasos de la empresa ST. Jude Medical. ........................................................................ 7 Figura 1.6. Programador Medtronic CareLink ................................................................................................ 11 Figura 1.7. Flujo de trabajo de un sistema gestor de información cardiológica. ............................ 12 Figura 1.8. Equipos usados para la transferencia de datos de manera remota............................. 12 Figura 1.9. Flujo de trabajo de un sistema de seguimiento remoto ...................................................... 13 Figura 1.10. Arquitectura del sistema BIOTRONIK Home Monitoring ................................................ 14 Figura 1.11. Funcionamiento del sistema Paceart de Medtronics. ....................................................... 15 Figura 3.1. Proceso de trabajo del IHE para la creación de nuevos perfiles ................................... 22 Figura 3.2. Componentes de un perfil del IHE. ............................................................................................... 23 Figura 3.3. Arquitectura del dominio PCD. ........................................................................................................ 23 Figura 3.4. Flujo de datos del perfil IHE-PCD-IDCO en situaciones clínico y remoto. ............... 25 Figura 3.5. Diagrama de actores y transacciones del perfil IHE-PCD-IDCO. ................................. 26 Figura 3.6. Flujo de información en un escenario IDCO. ........................................................................... 29 Figura 3.7. Obtención del Identificador del Paciente. .................................................................................. 32 Figura 3.8. Funcionamiento de la transacción PCD- 09. ........................................................................... 32 Figura 3.9 Estructura del mensaje ACK. ............................................................................................................ 43 Figura 4.1. Flujo de datos en situaciones clínico y remoto ....................................................................... 47 Figura 4.2. Arquitectura de Mirth. ........................................................................................................................... 52 Figura 4.3. Dashboard de Iguana. ......................................................................................................................... 53 Figura 4.4. Entorno de desarrollo de Iguana para la creación de traductores. ............................... 54 Figura 4.5. Configuración de datos de entrada del canal. ......................................................................... 55 Figura 4.6. Configuración de datos de salida del canal.............................................................................. 56 Figura 4.7. Entorno integrado de trabajo para la generación de traductores. ................................. 56 Figura 4.8. Imagen de las tabla id_marca_patient_tbl................................................................................. 57 Figura 4.9. Imagen de las tabla patient_tbl ....................................................................................................... 57 Figura 4.10. Configuración de datos de entrada del canal ....................................................................... 59 Figura 4.11. Configuración de datos de salida del canal. .......................................................................... 60 Figura 4.12. Interfaz gráfica del software Chamaleon................................................................................. 61 Figura 4.13. Pantalla de acceso al sistema Openclinc................................................................................ 66 Figura 4.14. Pantalla de inicio de OpenClinic .................................................................................................. 67 Figura 4.15. Modulo de Historia Clinica del sistema OpenClinic ........................................................... 67 Figura 4.16. Tablas contenidas en la base de datos OpenClinic........................................................... 68 Figura 4.17.Reporte final en el historial del paciente del sistema Openclinic ................................. 69 Figura 4.18. Campos de la tabla datos_marcapasos. ................................................................................. 70

133

Lista de Tablas

LISTA DE TABLAS
Tabla 1.1. Componentes del corazón ..................................................................................... 2 Tabla 1.2. Empresas manufactureras de marcapasos. ......................................................... 10 Tabla 1.3 Perfiles del dominio Patient Care Device (PCD). ................................................... 24 Tabla 1.4 Funciones de los actores del perfil IHE-PCD-ICDO............................................... 27 Tabla 1.5 Estructura del mensaje HL7/ORU. ........................................................................ 33 Tabla 1.6 Estructura del segmento MSH............................................................................... 34 Tabla 1.7 Estructura del segmento PID................................................................................. 36 Tabla 1.8 HL7 Table 023. ..................................................................................................... 36 Tabla 1.9 HL7 Table 0001..................................................................................................... 37 Tabla 1.10 Estructura del segmento PV1. ............................................................................. 38 Tabla 1.11 HL7 Table 0004................................................................................................... 38 Tabla 1.12 Estructura del segmento OBR. ............................................................................ 39 Tabla 1.13 Estado del mensaje............................................................................................. 40 Tabla 1.14 Estructura del segmento OBX. ............................................................................ 40 Tabla 1.15 HL7 Table 0001................................................................................................... 41 Tabla 1.16 HL7 Table 0085................................................................................................... 42 Tabla 1.17 Estructura del segmento NTE. ............................................................................ 42 Tabla 1.18 Valores posibles del primer campo de la cabecera MSA. .................................... 43 Tabla 1.19 Estructura de un mensaje HL7 con el estándar LLP. ........................................... 44 Tabla 1.20 Descripciones de autores del proyecto. ............................................................... 49

134

Bibliografía

8. Bibliografía

1 2 3

http://www.texasheartinstitute.org/HIC/anatomy_Esp/anato_sp.cfm http://masquecorazon.com/anatomiacorazon.html CATALINA TOBÓN ZULUAGA.2009.EVALUACIÓN DE FACTORES QUE PROVOCAN FIBRILACIÓN AURICULAR Y DE SU TRATAMIENTO MEDIANTE TÉCNICAS QUIRÚRGICAS. ESTUDIO DE SIMULACIÓN. Valencia. http://www.yalemedicalgroup.org/stw/Page.asp?PageID=STW027669. Marian Bas Villalobos.2010 PROPUESTA DE UN SISTEMA DE MONITORIZACIÓN REMOTA DE DISPOSITIVOS IMPLANTADOS ENPACIENTES CARDIOLÓGICOS. CONSIDERACIONES ECONÓMICAS, ORGANIZATIVAS Y DE CALIDAD PERCIBIDA.Madrid http://www.ate.uniovi.es/8695/documentos/TRABAJOS%202008/avances/viernes %2016-01-09%20bio/10-30/G5%20El%20marcapasos.pdf http://www.biotronik.com/biohm/the-new-biotronik-home-monitoring/18593 John G. Rhoads, Todd Cooper, Ken Fuchs, Paul Schluter, and Raymond Peter Zambut .2009.Medical Device Interoperability and the Integrating the Healthcare Enterprise (IHE) Initiative. http://www.ihe-europe.net/drupal/sites/default/files/IHE_Basics_SP.pdf

4 5

6 7 8

9

10 http://www.ihe-e.org/intro.htm 11 http://www.ihe.net/Technical_Framework/upload/IHE_PCD_TF_Vol2_FT_201108-12.pdf 12 http://es.wikipedia.org/wiki/HL7. 13 http://www.interfaceware.com/understanding_hl7_messages.html 14 Arquitectura Orientada a Servicios para Sistemas que utilizan HL7 Pablo Pazos Gutiérrez-Samanta de Barros Taller de Sistemas de Información , Instituto de Computación Facultad de Ingeniería, Universidad de la República. 15 http://www.desarrolloweb.com/articulos/1112.php

135

Sign up to vote on this title
UsefulNot useful