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

Universidad de Valencia Universidad de Valencia Universidad Politécnica de

Valencia

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

1.1.1 Funcionamiento del corazón. ......................................................................................................... 1

1.1.2 Sistema eléctrico del corazón. ....................................................................................................... 3

1.1.3 Alteraciones del ritmo cardiaco. .................................................................................................... 4

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

1.2.1 Componentes de un marcapasos. ............................................................................................... 5

1.2.2 Funcionamiento. .................................................................................................................................... 6

1.2.3 Tipos de Marcapasos. ........................................................................................................................ 7

1.2.3.1 Marcapasos temporales. ......................................................................................................... 7

1.2.3.2 Marcapasos Permanentes. .................................................................................................... 7

1.2.4 Conceptos de Marcapasos. ........................................................................................................... 8

1.2.5 Nomenclatura. ........................................................................................................................................ 8

1.2.6 Nueva generación de marcapasos. ............................................................................................ 9

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

1.3.1 Sistemas gestores de información cardiológica. ............................................................... 11

1.3.1.1 Sistemas de seguimiento remoto. ................................................................................... 12

1.3.2 Soluciones comerciales. ................................................................................................................ 14

1.3.2.1 Biotronik Home Monitoring. ................................................................................................ 14

1.3.2.2 Medtronics Paceart. ................................................................................................................ 15

2 Justificación. ................................................................................................................ 17

2.1 Objetivos. ........................................................................................................................................................ 18

2.1.1 Objetivo General. ............................................................................................................................... 18

2.1.2 Objetivos Específicos. ..................................................................................................................... 19

3. Metodología. ................................................................................................................ 20

3.1 IHE (Integrating the Healthcare Enterprise). ................................................................................. 20

3.1.1 Dominios del IHE. .............................................................................................................................. 21

3.1.2 Cómo funciona los perfiles del IHE. ......................................................................................... 21

3.2 Dominio IHE-PCD (Patient Care Device). ...................................................................................... 23

3.2.1 Perfiles del dominio IHE-PCD(Patient Care Device) ....................................................... 24

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

Tabla de contenidos

3.3.1 Introducción. ......................................................................................................................................... 25

3.3.2 Actores y transacciones. ................................................................................................................ 26

3.3.3 Descripción funcional ...................................................................................................................... 27

3.3.4 Estándares............................................................................................................................................ 28

3.3.4.1 HL7 V2.5x ORU ........................................................................................................................ 28

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

3.3.5.1 IEEE 11073_10103. ............................................................................................................... 30

3.3.6 Consideraciones de Identificación del paciente. ............................................................... 31

3.3.7.1 Mensaje HL7/ORU. ............................................................................................................... 32

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 Mensaje de Autentificación (ACK). ................................................................................. 43

3.3.7.3 LLP- Lower Layer Protocol. ............................................................................................... 44

4. Soluciones Planteadas. ............................................................................................... 46

4.1 Casos de uso. ............................................................................................................................................... 46

4.1.1 En el hospital. ...................................................................................................................................... 46

4.1.2 Remoto. .................................................................................................................................................. 46

4.2 Identificación de actores.......................................................................................................................... 48

4.3 Diseño del actor DOR(Device Cardiac Reporter) ...................................................................... 50

4.3.1 Mirth. ........................................................................................................................................................ 51

4.3.2 Iguana. .................................................................................................................................................... 53

4.3.2.1 Diseño de canales de entrada. ......................................................................................... 55

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

4.4.1 Datos de entrada del canal. ......................................................................................................... 59

4.4.2 Datos de salida del canal. ............................................................................................................. 60

4.4.2.1 Chamaleon. ................................................................................................................................. 61

4.4.2.2 Flujo de trabajo del actor DOC. ........................................................................................ 63

4.5 Sistema gestor de historia clínica OpenClinic .............................................................................. 64

4.5.1 Servidor Web Apache. .................................................................................................................... 65

4.5.1.1 Arquitectura del servidor Apache. ................................................................................... 65

4.5.2 Interfaz OpenClinic. .......................................................................................................................... 66

4.5.3 Base de datos del software OpenClinic. ................................................................................ 68

4.5.4 Modificaciones realizadas a OpenClinic. ............................................................................... 69

5. Resultados. .................................................................................................................. 71

5.1 Sistema OpenClinic. .................................................................................................................................. 72

6 Conclusiones. .............................................................................................................. 80

7 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

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.

Introducción

2

Tabla 1.1. Componentes del corazón

Nombre Función

Aurícula derecha 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, aórtica, y mitral.

Su función es poder mantener aislado por un 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

Introducción

3

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.

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

Introducción

4

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.

Figura 1.2. Sistema eléctrico del corazón

Introducción

5

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.

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.

Figura 1.3. Componentes de un marcapasos genérico.

Introducción

6

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.

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.

Figura 1.4. Figura de un marcapasos implantado

Introducción

7

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

1.2.3.2 Marcapasos Permanentes.

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.

Introducción

8

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.

Introducción

9

Tabla de nomenclatura de marcapasos

Posición Nombre Valores

X Estimulación: Identifica la cámara estimulada

0 Ninguna A Aurícula V Ventrículo D Doble S Single (denominación de fábrica)

Y Detección: Identifica la cámara censada.

0 Ninguna A Aurícula V Ventrículo D Doble S Single (denominación de fábrica)

Z Respuesta: El modo de respuesta del marcapasos.

0 Ninguna T Disparado I Inhibido D Disparado + inhibido

A Programabilidad: Indica las funciones programables.

0 Ninguna C Comunicación, telemetría P Mono o biprogramable M Multiprogramable R Frecuencia variable

B Anti taquicardia: Funciones programables de anti taquicardia.

0 Ninguna P Estimulación S Choque D Estimulación + choque

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-marcapasos-programador 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

Introducción

10

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. American Pacemaker Corp. Biotronik

Boston Scientific

Cardiac Control Systems

Cardiac Impulse

Cardio-Pace Medical

Cook Pacemaker Corp.

Coratomic Inc.

Cordis

ELA Medical

Guidant

Intermedics

Implantronik

Medico

Medtronic

Oscor

Osypka

Pacesetter

Siemens

Somedics

Sorin

St.Jude Medical

Stoeckert

Teletronics

Ventritex

Vitatron

Introducción

11

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.

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

Figura 1.6. Programador Medtronic CareLink

Introducción

12

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). Los sistemas de interrogación remota pueden funcionar en dos modos:

• Interrogación continuada.

• Interrogación programada.

Paciente

Programador

Doctor

Figura 1.7. Flujo de trabajo de un sistema gestor de información

cardiológica.

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

Introducción

13

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

Introducción

14

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

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.

Paciente Sistema de

comunicació

n

Servidor

BIOTRONIK

Aplicación

Web Doctor

Figura 1.10. Arquitectura del sistema BIOTRONIK Home Monitoring

Introducción

15

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.

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

Figura 1.11. Funcionamiento del sistema Paceart de Medtronics.

Introducción

16

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.

Justificación

17

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.

El cuidado óptimo del paciente exige que los proveedores de salud y 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

Justificación

18

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

Justificación

19

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.

Metodología

20

3. METODOLOGÍ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

Metodología

21

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

Metodología

22

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

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

Metodología

23

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

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.

Biotronik Home

Monitoring

Sistema gestor

de

información

hospitalaria

Actor

Transacción

Actor

Información

Figura 3.2. Componentes de un perfil del IHE.

Figura 3.3. Arquitectura del dominio PCD.

Metodología

24

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

Metodología

25

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.

Metodología

26

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.

Metodología

27

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 Función

Implantable Device – Cardiac – Reporter (DOR) 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

Metodología

28

ó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-PCD-IDCO 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:

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

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

Metodología

29

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.

3.3.5 Proceso de trabajo del IHE-PCD-IDCO.

Carácter Función

0x0D 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

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

Metodología

30

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

Metodología

31

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.

Metodología

32

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.

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.

Sistema gestor de

información cardiológica

Id: BSC/1234/ ERYU Nombre: Alvaro Cortes Mánica Teléfono: 622496545 SS: 7878899999

….

Paciente

Id: BSC/1234/ ERYU

Registro electrónico del

paciente

PCD-09

Device Observation

Reporter

Device Observation

Consumer HL7 ORU Observación

Figura 3.7. Obtención del Identificador del Paciente.

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

Metodología

33

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.

Metodología

34

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.

Metodología

35

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.

Metodología

36

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.

Metodología

37

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.

Metodología

38

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 por el actor DOR. Ejemplo: EB7A5C4F4A0098B2BCE3063BE6FDBD06.

Metodología

39

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.

Metodología

40

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.

Metodología

41

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 IHE-

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

Metodología

42

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.

Metodología

43

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.

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

Figura 3.9 Estructura del mensaje ACK.

Metodología

44

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

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

Valor Significado

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

Metodología

45

Tabla 1.19 Estructura de un mensaje HL7 con el estándar LLP.

Cabecera Hl7 mensaje Trailer Retorno

de carro

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)

Caracter

(0x0D)

Soluciones

46

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.

Soluciones

47

La figura siguiente muestra el flujo de trabajo

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

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

Soluciones

48

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.

Soluciones

49

Tabla 1.20 Descripciones de autores del proyecto.

Nombre del sistema Nombre Actor según el perfil

IHE-PCD-IDCO

Función

Servidor web vendor.

Sistema gestor de información

Implantable Device –

Cardiac – Reporter (DOR)

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.

Sistema gestor de historia clínica

Implantable Device –

Cardiac – Consumer (DOC)

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.

Se muestra a continuación el diagrama de actores definido en el perfil IHE-PCD-IDCO, con los sistemas participantes en el proyecto.

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.

Servidor web

Vendor

Sistema gestor

de información

DOR

Sistema gestor de

historia clínica

DOC

PCD-09

Soluciones

50

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.

Soluciones

51

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

Soluciones

52

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

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/

Figura 4.2. Arquitectura de Mirth.

Soluciones

53

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.

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.

Figura 4.3. Dashboard de Iguana.

Soluciones

54

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.

Soluciones

55

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.

Figura 1

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

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

Soluciones

56

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.

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.

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.

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

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

Soluciones

57

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.

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.

Figura 4.8. Imagen de las tabla id_marca_patient_tbl

Figura 4.9. Imagen de las tabla patient_tbl

Soluciones

58

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.

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

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

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

XML

IEEE 11073

- 10103 -

MDC-IDC

Canal file_to_channel

DOR

DB

DOC

Soluciones

59

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.

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.

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

Soluciones

60

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.

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.

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

Soluciones

61

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.

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

Figura 4.12. Interfaz gráfica del software Chamaleon.

Soluciones

62

Soluciones

63

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.

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

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

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.

Canal

File_to_channel

DOC

DB

DOR Chamaleon

Soluciones

64

1 El mensaje en formato HL7/ORU llega la canal de entrada para su procesamiento.

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

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

4 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”.

De esta manera se tenía ya el diseño de los actores involucrados según el perfil IHE-

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

Soluciones

65

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.

4.5.1.1 Arquitectura del servidor Apache.

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.

Soluciones

66

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

Soluciones

67

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)

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.14. Pantalla de inicio de OpenClinic

Figura 4.15. Modulo de Historia Clinica del sistema OpenClinic

Soluciones

68

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

Soluciones

69

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)

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.

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

Soluciones

70

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.

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.

Figura 4.18. Campos de la tabla datos_marcapasos.

Resultados

71

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.

Resultados

72

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: Cortes Manica Alvaro

Fecha de nacimiento: 06/02/1984

Sexo: Hombre

Fecha de interrogación, Tipo: 01/10/2010 1:39 AM, Remote

Feca de la inerrogacion anterior, Tipo,

Program:

20/04/2010 11:50 AM, In-Clinic ,No reprogramado

Nombre del Doctor, Clinic: Thomas Berger, any clinic

Contacto: Fax: +123456

Resultados

73

Datos del dispositivo:

Datos del Electrodo:

Lead Lead 1

Ubicacion: RV

Detalles de ubicacion: --

Fecha de implatacion: 05/01/2005

Manufacturado por: --

Modelo: --

Numero de serie: --

Polaridad: Bipolar

Estado: Conectado

Lead Special Function: --

Tipo de Dispositivo: ICD

Empresa Manufacturera: Biotronik

Modelo del dispositivo: Lumax 300 VR-T

Numero de serie del dispositivo: 110011

Fecha de implante: 03/11/2003 11:31:24

Dr. que lo implanto/ Lugar: No disponible

Numero Contacto: No disponible

Resultados

74

Estado de la Batería:

Estado del capacitor:

Fecha de revisión de la batería : 01/08/2010

Estado : MOS

Voltaje: 6.3 V

Bateria restante (%): 68.0 %

Fecha de carga: 27/05/2010

Tiempo de carga (s): 8.5

Energia de carga: 30J

Tipo de Carga: Reformation

Resultados

75

Medidas del electrodo:

Medidas del electrodo / Estado

Dia/fecha de la observación:

01/08/2010 01:55 - 01/08/2010 01:55

RV

Amplitud intrínseca media:

12.9 mV (BP)

Amplitud intrínseca mínima:

12.9 mV (BP)

Impedancia: > 440 Ω (BP)

Umbral de estimulación:

0.6 V @

0.5 ms 0.4 V @

0.5 ms

(UP) (BP)

Método de medida: --

Estado del electrodo: Null

Resultados

76

Estadísticas:

Shock Lead Configuration and Measurement

Cátodo- – Ánodo Impedancia, Fecha/Time, Tipo de medida Estado

RV 52 Ω, 01/08/2010, low-voltage Null

RV 28 Ω, 02/26/2010, Shock CheckLead

Bradicardia

Taquicardia auricular 3)

Estimulación RA : -- AT/AF por dia: --

Estimulación RV : 10 % 2) Max. ModeSw-Epis: --

AP-VP: -- Tiempo ModeSw (dias): --

AS-VP: -- Numero de ModeSw (dias): --

AP-VS: --

AS-VS: -- CRT

Estimulación LV : --

Frecuencia cardiaca de la

aurícula

-- Estimulación CRT: --

Frecuencia cardiaca del

Ventriculo1):

67 bpm

Resultados

77

Episodios:

Episodios

Terapias

Tipos Total Fecha Tipos Total Fecha

VF 9 08/01/2010

01:55:36 Shocks entregados 0 08/01/2010

01:55:36

VT1 0 08/01/2010

01:55:36 Shocks abortados 9 08/01/2010

01:55:36

SVT 0 08/01/2010

01:55:36 ATPs 0 08/01/2010

01:55:36

Episode List

ID Fecha/Tiempo Tipo Inducido

1 08/01/2010 01:55:36 VF NO

2 08/01/2010 01:55:36 VT1 NO

3 08/01/2010 01:55:36 VT NO

4 08/01/2010 01:55:36 SVT NO

Configuraciones del Dispositivo:

Config.de Bradicardia Config. Taquiaritmia auricular

Mode: VVI Modo AT: --

Rango inferior: 45 bpm Rango de cambio

Modo AT:

--

Rango de histeresis: --

Rango nocturno: -- Config. CRT

Tipo de sensor: Acelerometro Ritmo CRT: --

Resultados

78

Rango máximo de

seguimiento:

-- Retraso LV-RV: --

Rango máximo del

sensor:

--

Retraso SAV: -- Modo de Imán: Tachyarrhythmia

detection therapy

temporarily deactivated PAV Delay: --

Configuraciones de la zona de taquiarritmia

Terapia Ventricular: ON Terapia

Aricular:

OFF

Zona Limite

bpm

Detection

X of Y

ATP Shocks Detalles Status Vendor

VF 195 280 ms 1x Burst 1x 30J, 1x 30J, 6x 30J No Disponble Active BIO-

Zone_VF

VT1 -- -- -- -- -- Inactivo BIO-

Zone_VT1

VT2 -- -- -- -- -- Inactivo BIO-

Zone_VT2

Lead Channel Settings

RV

Sensibilidad: 1.3 mV (adaptive)

Polaridad: Bipolar

Vector: RV Tip – RV Ring

Estimulación de salida: 4.0 V (adaptive)

Ancho de pulso de la

estimulación

1 ms

Resultados

79

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.

Conclusión

80

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.

Conclusión

81

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 IHE-PCD-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.

Anexos

82

7 Anexos

Nomenclatura IEEE 11073 MDC_IDC

Reference ID Systematic Name Code Enumeration

MDC_IDC_PG_TYPE type | pulse generator | implantable device cardiac | medical device communication

720897

MDC_IDC_ENUM_DEVICE_TYPE

MDC_IDC_PG_MODEL model | pulse generator | implantable device cardiac | medical device communication

720898

MDC_IDC_PG_SERIAL serial number | pulse generator | implantable device cardiac | medical device communication

720899

MDC_IDC_PG_MFG manufacturer | pulse generator | implantable device cardiac | medical device communication

720900

MDC_IDC_ENUM_MFG

MDC_IDC_PG_IMPLANT_DT implant date | pulse generator | implantable device cardiac | medical device communication

720901

MDC_IDC_PG_IMPLANTER implanter | pulse generator | implantable device cardiac | medical device communication

720902

MDC_IDC_PG_IMPLANTER_CONTACT_INFO implanter contact information | pulse generator | implantable device cardiac | medical device communication

720903

MDC_IDC_PG_IMPLANTING_FACILITY implanting facility | pulse

generator | implantable device cardiac | medical device communication

72090

4

MDC_IDC_LEAD_MODEL model | lead | implantable device cardiac | medical device communication

720961

MDC_IDC_LEAD_SERIAL serial number | lead | implantable device cardiac | medical device communication

720962

MDC_IDC_LEAD_MFG manufacturer | lead | implantable device cardiac | medical device communication

720963

MDC_IDC_ENUM_MFG

MDC_IDC_LEAD_IMPLANT_DT implant date | lead | implantable device cardiac | medical device communication

720964

MDC_IDC_LEAD_POLARITY_TYPE polarity type | lead | implantable device cardiac | medical device communication

720965

MDC_IDC_ENUM_LEAD_POLARITY_TYPE

MDC_IDC_LEAD_LOCATION location | lead | implantable device cardiac | medical device communication

720966

MDC_IDC_ENUM_LEAD_LOCATION_CHAMBER

MDC_IDC_LEAD_LOCATION_DETAIL_1 detail 1 | location | lead | implantable device cardiac | medical device communication

720967

MDC_IDC_ENUM_LEAD_LOCATION_DETAIL

MDC_IDC_LEAD_LOCATION_DETAIL_2 detail 2 | location | lead | implantable device cardiac | medical device communication

720968

MDC_IDC_ENUM_LEAD_LOCATION_DETAIL

MDC_IDC_LEAD_LOCATION_DETAIL_3 detail 3 | location | lead | implantable device cardiac

720969

MDC_IDC_ENUM_LEAD_LOCATION_DETAIL

Anexos

83

| medical device communication

MDC_IDC_LEAD_CONNECTION_STATUS connection status | lead | implantable device cardiac | medical device communication

720970

MDC_IDC_ENUM_LEAD_STATUS

MDC_IDC_LEAD_SPECIAL_FUNCTION special function | lead | implantable device cardiac | medical device communication

720971

MDC_IDC_SESS_DTM date time | session | implantable device cardiac | medical device communication

721025

MDC_IDC_SESS_TYPE type | session | implantable device cardiac | medical device communication

721026

MDC_IDC_ENUM_SESS_TYPE

MDC_IDC_SESS_REPROGRAMMED reprogrammed | session | implantable device cardiac | medical device communication

721027

MDC_IDC_ENUM_SESS_REPROGRAMMED

MDC_IDC_SESS_DTM_PREVIOUS previous date time | session | implantable device cardiac | medical device communication

721028

MDC_IDC_SESS_TYPE_PREVIOUS previous type | session | implantable device cardiac | medical device communication

721029

MDC_IDC_ENUM_SESS_TYPE

MDC_IDC_SESS_REPROGRAMMED_PREVIOUS reprogrammed previous | session | implantable device cardiac | medical device communication

721030

MDC_IDC_ENUM_SESS_REPROGRAMMED

MDC_IDC_SESS_CLINICIAN_NAME clinician name | session | implantable device cardiac | medical device communication

721031

MDC_IDC_SESS_CLINICIAN_CONTACT_INFORMATION clinician contact information | session |

implantable device cardiac | medical device communication

721032

MDC_IDC_SESS_CLINIC_NAME clinic name | session | implantable device cardiac | medical device communication

721033

MDC_IDC_MSMT_DTM date time | measurement | implantable device cardiac | medical device communication

721152

MDC_IDC_MSMT_DTM_START date time | measurement | implantable device cardiac | medical device communication start

721153

MDC_IDC_MSMT_DTM_END date time | measurement | implantable device cardiac | medical device communication end

721154

MDC_IDC_MSMT_BATTERY_DTM date time | battery | measurement | implantable device cardiac | medical device communication

721216

MDC_IDC_MSMT_BATTERY_STATUS status | battery | measurement | implantable device cardiac | medical device communication

721280

MDC_IDC_ENUM_BATTERY_STATUS

MDC_IDC_MSMT_BATTERY_VOLTAGE voltage | battery | measurement | implantable device cardiac | medical device communication

721344

MDC_IDC_MSMT_BATTERY_IMPEDANCE impedance | battery | measurement |

721408

Anexos

84

implantable device cardiac | medical device communication

MDC_IDC_MSMT_BATTERY_REMAINING_LONGEVITY remaining longevity | battery | measurement | implantable device cardiac | medical device communication

721472

MDC_IDC_MSMT_BATTERY_REMAINING_PERCENTAGE remaining percentage | battery | measurement | implantable device cardiac | medical device communication

721536

MDC_IDC_MSMT_BATTERY_RRT_TRIGGER recommended replacement time trigger | battery | measurement | implantable device cardiac | medical device communication

721600

MDC_IDC_MSMT_CAP_CHARGE_DTM last charge date time | capacitor | measurement | implantable device cardiac | medical device communication

721664

MDC_IDC_MSMT_CAP_CHARGE_TIME charge time | capacitor | measurement | implantable device cardiac | medical device communication

721728

MDC_IDC_MSMT_CAP_CHARGE_ENERGY charge energy | capacitor | measurement | implantable device cardiac | medical device communication

721792

MDC_IDC_MSMT_CAP_CHARGE_TYPE charge type | capacitor | measurement | implantable device cardiac | medical device communication

721856

MDC_IDC_ENUM_CHARGE_TYPE

MDC_IDC_MSMT_LEADCHNL_RA_DTM date time | lead channel right atrial | measurement | implantable device cardiac | medical device communication

721920

MDC_IDC_MSMT_LEADCHNL_RA_DTM_START date time start | lead channel right atrial | measurement | implantable device cardiac | medical device communication

721921

MDC_IDC_MSMT_LEADCHNL_RA_DTM_END date time end | lead channel right atrial | measurement | implantable device cardiac | medical device communication

721922

MDC_IDC_MSMT_LEADCHNL_RV_DTM date time | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

721924

MDC_IDC_MSMT_LEADCHNL_RV_DTM_START date time start | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

721925

MDC_IDC_MSMT_LEADCHNL_RV_DTM_END date time end | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

721926

MDC_IDC_MSMT_LEADCHNL_LA_DTM date time | lead channel left atrial | measurement | implantable device cardiac

721928

Anexos

85

| medical device communication

MDC_IDC_MSMT_LEADCHNL_LA_DTM_START date time start | lead channel left atrial | measurement | implantable device cardiac | medical device communication

721929

MDC_IDC_MSMT_LEADCHNL_LA_DTM_END date time end | lead channel left atrial | measurement | implantable device cardiac | medical device communication

721930

MDC_IDC_MSMT_LEADCHNL_LV_DTM date time | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

721932

MDC_IDC_MSMT_LEADCHNL_LV_DTM_START date time start | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

721933

MDC_IDC_MSMT_LEADCHNL_LV_DTM_END date time end | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

721934

MDC_IDC_MSMT_LEADCHNL_RA_LEAD_CHANNEL_STATUS

lead channel status | lead channel right atrial | measurement | implantable device cardiac | medical device communication

721984

MDC_IDC_ENUM_CHANNEL_STATUS

MDC_IDC_MSMT_LEADCHNL_RV_LEAD_CHANNEL_STATUS

lead channel status | lead channel right ventricle |

measurement | implantable device cardiac | medical device communication

721985

MDC_IDC_ENUM_CHANNEL_STATUS

MDC_IDC_MSMT_LEADCHNL_LA_LEAD_CHANNEL_STATUS

lead channel status | lead channel left atrial | measurement | implantable device cardiac | medical device communication

721986

MDC_IDC_ENUM_CHANNEL_STATUS

MDC_IDC_MSMT_LEADCHNL_LV_LEAD_CHANNEL_STATUS

lead channel status | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

721987

MDC_IDC_ENUM_CHANNEL_STATUS

MDC_IDC_MSMT_LEADCHNL_RA_SENSING_INTR_AMPL sensing intrinsic amplitude | lead channel right atrial | measurement | implantable device cardiac | medical device communication

722048

MDC_IDC_MSMT_LEADCHNL_RA_SENSING_INTR_AMPL_MAX

sensing intrinsic amplitude maximum | lead channel right atrial | measurement | implantable device cardiac | medical device communication

722049

MDC_IDC_MSMT_LEADCHNL_RA_SENSING_INTR_AMPL_MIN

sensing intrinsic amplitude minimum | lead channel right atrial | measurement | implantable device cardiac | medical device communication

722050

MDC_IDC_MSMT_LEADCHNL_RA_SENSING_INTR_AMPL_MEAN

sensing intrinsic amplitude mean | lead channel right atrial | measurement |

722051

Anexos

86

implantable device cardiac | medical device communication

MDC_IDC_MSMT_LEADCHNL_RV_SENSING_INTR_AMPL sensing intrinsic amplitude | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

722052

MDC_IDC_MSMT_LEADCHNL_RV_SENSING_INTR_AMPL_MAX

sensing intrinsic amplitude maximum | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

722053

MDC_IDC_MSMT_LEADCHNL_RV_SENSING_INTR_AMPL_MIN

sensing intrinsic amplitude minimum | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

722054

MDC_IDC_MSMT_LEADCHNL_RV_SENSING_INTR_AMPL_MEAN

sensing intrinsic amplitude mean | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

722055

MDC_IDC_MSMT_LEADCHNL_LA_SENSING_INTR_AMPL sensing intrinsic amplitude | lead channel left atrial | measurement | implantable device cardiac | medical device communication

722056

MDC_IDC_MSMT_LEADCHNL_LA_SENSING_INTR_AMPL_MAX

sensing intrinsic amplitude maximum | lead channel left atrial | measurement | implantable device cardiac | medical device communication

722057

MDC_IDC_MSMT_LEADCHNL_LA_SENSING_INTR_AMPL_MIN

sensing intrinsic amplitude minimum | lead channel left atrial | measurement | implantable device cardiac | medical device communication

722058

MDC_IDC_MSMT_LEADCHNL_LA_SENSING_INTR_AMPL_MEAN

sensing intrinsic amplitude mean | lead channel left atrial | measurement | implantable device cardiac | medical device communication

722059

MDC_IDC_MSMT_LEADCHNL_LV_SENSING_INTR_AMPL sensing intrinsic amplitude | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

722060

MDC_IDC_MSMT_LEADCHNL_LV_SENSING_INTR_AMPL_MAX

sensing intrinsic amplitude maximum | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

722061

MDC_IDC_MSMT_LEADCHNL_LV_SENSING_INTR_AMPL_MIN

sensing intrinsic amplitude minimum | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

722062

MDC_IDC_MSMT_LEADCHNL_LV_SENSING_INTR_AMPL_MEAN

sensing intrinsic amplitude mean | lead channel left ventricle | measurement | implantable device cardiac

722063

Anexos

87

| medical device communication

MDC_IDC_MSMT_LEADCHNL_RA_SENSING_POLARITY sensing polarity | lead channel right atrial | measurement | implantable device cardiac | medical device communication

722112

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_RV_SENSING_POLARITY sensing polarity | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

722113

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_LA_SENSING_POLARITY sensing polarity | lead channel left atrial | measurement | implantable device cardiac | medical device communication

722114

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_LV_SENSING_POLARITY sensing polarity | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

722115

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_RA_PACING_THRESHOLD_AMPLITUDE

amplitude | pacing threshold | lead channel right atrial | measurement | implantable device cardiac | medical device communication

722176

MDC_IDC_MSMT_LEADCHNL_RV_PACING_THRESHOLD_AMPLITUDE

amplitude | pacing threshold | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

722177

MDC_IDC_MSMT_LEADCHNL_LA_PACING_THRESHOLD_A

MPLITUDE amplitude | pacing

threshold | lead channel left atrial | measurement | implantable device cardiac | medical device communication

72217

8

MDC_IDC_MSMT_LEADCHNL_LV_PACING_THRESHOLD_AMPLITUDE

amplitude | pacing threshold | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

722179

MDC_IDC_MSMT_LEADCHNL_RA_PACING_THRESHOLD_PULSEWIDTH

pulsewidth | pacing threshold | lead channel right atrial | measurement | implantable device cardiac | medical device communication

722240

MDC_IDC_MSMT_LEADCHNL_RV_PACING_THRESHOLD_PULSEWIDTH

pulsewidth | pacing threshold | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

722241

MDC_IDC_MSMT_LEADCHNL_LA_PACING_THRESHOLD_PULSEWIDTH

pulsewidth | pacing threshold | lead channel left atrial | measurement | implantable device cardiac | medical device communication

722242

MDC_IDC_MSMT_LEADCHNL_LV_PACING_THRESHOLD_PULSEWIDTH

pulsewidth | pacing threshold | lead channel left ventricle | measurement | implantable device cardiac | medical device

722243

Anexos

88

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

722304

MDC_IDC_ENUM_MEASUREMENT_METHOD

MDC_IDC_MSMT_LEADCHNL_RV_PACING_THRESHOLD_MEASUREMENT_METHOD

measurement method | pacing threshold | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

722305

MDC_IDC_ENUM_MEASUREMENT_METHOD

MDC_IDC_MSMT_LEADCHNL_LA_PACING_THRESHOLD_MEASUREMENT_METHOD

measurement method | pacing threshold | lead channel left atrial | measurement | implantable device cardiac | medical device communication

722306

MDC_IDC_ENUM_MEASUREMENT_METHOD

MDC_IDC_MSMT_LEADCHNL_LV_PACING_THRESHOLD_MEASUREMENT_METHOD

measurement method | pacing threshold | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

722307

MDC_IDC_ENUM_MEASUREMENT_METHOD

MDC_IDC_MSMT_LEADCHNL_RA_PACING_THRESHOLD_POLARITY

polarity | pacing threshold | lead channel right atrial | measurement | implantable device cardiac | medical device communication

722368

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_RV_PACING_THRESHOLD_POLARITY

polarity | pacing threshold | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

722369

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_LA_PACING_THRESHOLD_POLARITY

polarity | pacing threshold | lead channel left atrial | measurement | implantable device cardiac | medical device communication

722370

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_LV_PACING_THRESHOLD_POLARITY

polarity | pacing threshold | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

722371

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_RA_IMPEDANCE_VALUE value | impedance | lead channel right atrial | measurement | implantable device cardiac | medical device communication

722432

MDC_IDC_MSMT_LEADCHNL_RV_IMPEDANCE_VALUE value | impedance | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

722433

MDC_IDC_MSMT_LEADCHNL_LA_IMPEDANCE_VALUE value | impedance | lead channel left atrial | measurement | implantable device cardiac | medical device communication

722434

MDC_IDC_MSMT_LEADCHNL_LV_IMPEDANCE_VALUE value | impedance | lead channel left ventricle | measurement | implantable device cardiac | medical device

722435

Anexos

89

communication

MDC_IDC_MSMT_LEADCHNL_RA_IMPEDANCE_POLARITY polarity | impedance | lead channel right atrial | measurement | implantable device cardiac | medical device communication

722496

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_RV_IMPEDANCE_POLARITY polarity | impedance | lead channel right ventricle | measurement | implantable device cardiac | medical device communication

722497

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_LA_IMPEDANCE_POLARITY polarity | impedance | lead channel left atrial | measurement | implantable device cardiac | medical device communication

722498

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADCHNL_LV_IMPEDANCE_POLARITY polarity | impedance | lead channel left ventricle | measurement | implantable device cardiac | medical device communication

722499

MDC_IDC_ENUM_POLARITY

MDC_IDC_MSMT_LEADHVCHNL_DTM date time | lead high voltage channel | measurement | implantable device cardiac | medical device communication

722560

MDC_IDC_MSMT_LEADHVCHNL_DTM_START date time start | lead high voltage channel | measurement | implantable device cardiac | medical device communication

722561

MDC_IDC_MSMT_LEADHVCHNL_DTM_END date time end | lead high voltage channel | measurement | implantable device cardiac | medical device communication

722562

MDC_IDC_MSMT_LEADHVCHNL_IMPEDANCE impedance | lead high voltage channel | measurement | implantable device cardiac | medical device communication

722624

MDC_IDC_MSMT_LEADHVCHNL_MEASUREMENT_TYPE measurement type | lead high voltage channel | measurement | implantable device cardiac | medical device communication

722688

MDC_IDC_ENUM_HVCHNL_MEASUREMENT_TYPE

MDC_IDC_MSMT_LEADHVCHNL_STATUS status | lead high voltage channel | measurement | implantable device cardiac | medical device communication

722752

MDC_IDC_ENUM_CHANNEL_STATUS

MDC_IDC_SET_CRT_LVRV_DELAY cardiac resynchronization therapy left ventricle right ventricle delay | setting | implantable device cardiac | medical device communication

729344

MDC_IDC_SET_CRT_PACED_CHAMBERS cardiac resynchronization therapy paced chambers | setting | implantable device cardiac | medical device communication

729408

MDC_IDC_ENUM_CRT_PACED_CHAMBERS

MDC_IDC_SET_MAGNET_RESP magnet response | setting | implantable device cardiac | medical device communication

729472

Anexos

90

MDC_IDC_SET_LEADCHNL_RA_SENSING_SENSITIVITY sensitivity | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729536

MDC_IDC_SET_LEADCHNL_RV_SENSING_SENSITIVITY sensitivity | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729537

MDC_IDC_SET_LEADCHNL_LA_SENSING_SENSITIVITY sensitivity | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729538

MDC_IDC_SET_LEADCHNL_LV_SENSING_SENSITIVITY sensitivity | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729539

MDC_IDC_SET_LEADCHNL_RA_SENSING_POLARITY polarity | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729600

MDC_IDC_ENUM_POLARITY

MDC_IDC_SET_LEADCHNL_RV_SENSING_POLARITY polarity | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729601

MDC_IDC_ENUM_POLARITY

MDC_IDC_SET_LEADCHNL_LA_SENSING_POLARITY polarity | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729602

MDC_IDC_ENUM_POLARITY

MDC_IDC_SET_LEADCHNL_LV_SENSING_POLARITY polarity | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729603

MDC_IDC_ENUM_POLARITY

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_LOCATION

anode location | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729664

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_LOCATION_1

anode location 1 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729665

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_LOCATION_2

anode location 2 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729666

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_LOCATION_3

anode location 3 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729667

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_LOCATION

anode location | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729680

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_LOCATION_1

anode location 1 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729681

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_LOCATION_2

anode location 2 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729682

Anexos

91

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_LOCATION_3

anode location 3 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729683

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_LOCATION

anode location | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729696

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_LOCATION_1

anode location 1 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729697

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_LOCATION_2

anode location 2 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729698

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_LOCATION_3

anode location 3 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729699

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_LOCATION

anode location | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729712

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_LOCATION_1

anode location 1 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729713

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_LOCATION_2

anode location 2 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical

device communication

729714

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_LOCATION_3

anode location 3 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729715

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_ELECTRODE

anode electrode | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729728

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_ELECTRODE_1

anode electrode 1 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729729

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_ELECTRODE_2

anode electrode 2 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729730

MDC_IDC_SET_LEADCHNL_RA_SENSING_ANODE_ELECTRODE_3

anode electrode 3 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729731

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_ELECTRODE

anode electrode | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729744

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_ELECTRODE_1

anode electrode 1 | sensing | lead channel right ventricle | setting |

729745

Anexos

92

implantable device cardiac | medical device communication

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_ELECTRODE_2

anode electrode 2 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729746

MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_ELECTRODE_3

anode electrode 3 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729747

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_ELECTRODE

anode electrode | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729760

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_ELECTRODE_1

anode electrode 1 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729761

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_ELECTRODE_2

anode electrode 2 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729762

MDC_IDC_SET_LEADCHNL_LA_SENSING_ANODE_ELECTRODE_3

anode electrode 3 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729763

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_ELECTRODE

anode electrode | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729776

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_ELECTRODE_1

anode electrode 1 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729777

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_ELECTRODE_2

anode electrode 2 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729778

MDC_IDC_SET_LEADCHNL_LV_SENSING_ANODE_ELECTRODE_3

anode electrode 3 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729779

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_LOCATION

cathode location | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729792

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_LOCATION_1

cathode location 1 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729793

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_LOCATION_2

cathode location 2 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729794

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_LOCATION_3

cathode location 3 | sensing | lead channel

729795

Anexos

93

right atrial | setting | implantable device cardiac | medical device communication

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_LOCATION

cathode location | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729808

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_LOCATION_1

cathode location 1 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729809

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_LOCATION_2

cathode location 2 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729810

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_LOCATION_3

cathode location 3 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729811

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_LOCATION

cathode location | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729824

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_LOCATION_1

cathode location 1 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729825

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_LOCATION_2

cathode location 2 | sensing | lead channel left

atrial | setting | implantable device cardiac | medical device communication

729826

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_LOCATION_3

cathode location 3 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729827

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_LOCATION

cathode location | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729840

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_LOCATION_1

cathode location 1 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729841

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_LOCATION_2

cathode location 2 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729842

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_LOCATION_3

cathode location 3 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729843

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_ELECTRODE

cathode electrode | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729856

Anexos

94

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_ELECTRODE_1

cathode electrode 1 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729857

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_ELECTRODE_2

cathode electrode 2 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729858

MDC_IDC_SET_LEADCHNL_RA_SENSING_CATHODE_ELECTRODE_3

cathode electrode 3 | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729859

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_ELECTRODE

cathode electrode | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729872

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_ELECTRODE_1

cathode electrode 1 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729873

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_ELECTRODE_2

cathode electrode 2 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729874

MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_ELECTRODE_3

cathode electrode 3 | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729875

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_ELECTRODE

cathode electrode | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729888

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_ELECTRODE_1

cathode electrode 1 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729889

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_ELECTRODE_2

cathode electrode 2 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729890

MDC_IDC_SET_LEADCHNL_LA_SENSING_CATHODE_ELECTRODE_3

cathode electrode 3 | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729891

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_ELECTRODE

cathode electrode | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729904

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_ELECTRODE_1

cathode electrode 1 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729905

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_ELECTRODE_2

cathode electrode 2 | sensing | lead channel left ventricle | setting |

729906

Anexos

95

implantable device cardiac | medical device communication

MDC_IDC_SET_LEADCHNL_LV_SENSING_CATHODE_ELECTRODE_3

cathode electrode 3 | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729907

MDC_IDC_SET_LEADCHNL_RA_SENSING_ADAPTATION_MODE

adaptation mode | sensing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729920

MDC_IDC_ENUM_SENSING_ADAPTION_MODE

MDC_IDC_SET_LEADCHNL_RV_SENSING_ADAPTATION_MODE

adaptation mode | sensing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729921

MDC_IDC_ENUM_SENSING_ADAPTION_MODE

MDC_IDC_SET_LEADCHNL_LA_SENSING_ADAPTATION_MODE

adaptation mode | sensing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729922

MDC_IDC_ENUM_SENSING_ADAPTION_MODE

MDC_IDC_SET_LEADCHNL_LV_SENSING_ADAPTATION_MODE

adaptation mode | sensing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729923

MDC_IDC_ENUM_SENSING_ADAPTION_MODE

MDC_IDC_SET_LEADCHNL_RA_PACING_AMPLITUDE amplitude | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

729984

MDC_IDC_SET_LEADCHNL_RV_PACING_AMPLITUDE amplitude | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

729985

MDC_IDC_SET_LEADCHNL_LA_PACING_AMPLITUDE amplitude | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

729986

MDC_IDC_SET_LEADCHNL_LV_PACING_AMPLITUDE amplitude | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

729987

MDC_IDC_SET_LEADCHNL_RA_PACING_PULSEWIDTH pulsewidth | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730048

MDC_IDC_SET_LEADCHNL_RV_PACING_PULSEWIDTH pulsewidth | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730049

MDC_IDC_SET_LEADCHNL_LA_PACING_PULSEWIDTH pulsewidth | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730050

MDC_IDC_SET_LEADCHNL_LV_PACING_PULSEWIDTH pulsewidth | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730051

MDC_IDC_SET_LEADCHNL_RA_PACING_POLARITY polarity | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730112

MDC_IDC_ENUM_POLARITY

MDC_IDC_SET_LEADCHNL_RV_PACING_POLARITY polarity | pacing | lead 73011 MDC_IDC_ENUM_POLARITY

Anexos

96

channel right ventricle | setting | implantable device cardiac | medical device communication

3

MDC_IDC_SET_LEADCHNL_LA_PACING_POLARITY polarity | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730114

MDC_IDC_ENUM_POLARITY

MDC_IDC_SET_LEADCHNL_LV_PACING_POLARITY polarity | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730115

MDC_IDC_ENUM_POLARITY

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_LOCATION

anode location | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730176

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_LOCATION_1

anode location 1 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730177

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_LOCATION_2

anode location 2 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730178

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_LOCATION_3

anode location 3 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730179

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_LOCATION

anode location | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730192

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_LOCATION_1

anode location 1 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730193

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_LOCATION_2

anode location 2 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730194

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_LOCATION_3

anode location 3 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730195

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_LOCATION

anode location | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730208

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_LOCATION_1

anode location 1 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730209

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_LOCATION_2

anode location 2 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730210

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_LOCATION_3

anode location 3 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730211

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_LOCATION

anode location | pacing | lead channel left ventricle |

730224

Anexos

97

setting | implantable device cardiac | medical device communication

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_LOCATION_1

anode location 1 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730225

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_LOCATION_2

anode location 2 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730226

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_LOCATION_3

anode location 3 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730227

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_ELECTRODE

anode electrode | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730240

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_ELECTRODE_1

anode electrode 1 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730241

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_ELECTRODE_2

anode electrode 2 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730242

MDC_IDC_SET_LEADCHNL_RA_PACING_ANODE_ELECTRODE_3

anode electrode 3 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730243

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_ELECTRODE

anode electrode | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730256

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_ELECTRODE_1

anode electrode 1 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730257

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_ELECTRODE_2

anode electrode 2 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730258

MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_ELECTRODE_3

anode electrode 3 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730259

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_ELECTRODE

anode electrode | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730272

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_ELECTRODE_1

anode electrode 1 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730273

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_ELECTRODE_2

anode electrode 2 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730274

Anexos

98

MDC_IDC_SET_LEADCHNL_LA_PACING_ANODE_ELECTRODE_3

anode electrode 3 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730275

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_ELECTRODE

anode electrode | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730288

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_ELECTRODE_1

anode electrode 1 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730289

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_ELECTRODE_2

anode electrode 2 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730290

MDC_IDC_SET_LEADCHNL_LV_PACING_ANODE_ELECTRODE_3

anode electrode 3 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730291

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_LOCATION

cathode location | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730304

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_LOCATION_1

cathode location 1 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730305

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_LOCATION_2

cathode location 2 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730306

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_LOCATION_3

cathode location 3 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730307

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_LOCATION

cathode location | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730320

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_LOCATION_1

cathode location 1 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730321

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_LOCATION_2

cathode location 2 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730322

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_LOCATION_3

cathode location 3 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730323

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_LOCATION

cathode location | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730336

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_LOCATION_1

cathode location 1 | pacing | lead channel left atrial | setting | implantable device cardiac | medical

730337

Anexos

99

device communication

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_LOCATION_2

cathode location 2 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730338

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_LOCATION_3

cathode location 3 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730339

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_LOCATION

cathode location | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730352

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_LOCATION_1

cathode location 1 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730353

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_LOCATION_2

cathode location 2 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730354

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_LOCATION_3

cathode location 3 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730355

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_ELECTRODE

cathode electrode | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730368

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_ELECTRODE_1

cathode electrode 1 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730369

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_ELECTRODE_2

cathode electrode 2 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730370

MDC_IDC_SET_LEADCHNL_RA_PACING_CATHODE_ELECTRODE_3

cathode electrode 3 | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730371

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_ELECTRODE

cathode electrode | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730384

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_ELECTRODE_1

cathode electrode 1 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730385

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_ELECTRODE_2

cathode electrode 2 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730386

MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_ELECTRODE_3

cathode electrode 3 | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730387

Anexos

100

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_ELECTRODE

cathode electrode | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730400

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_ELECTRODE_1

cathode electrode 1 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730401

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_ELECTRODE_2

cathode electrode 2 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730402

MDC_IDC_SET_LEADCHNL_LA_PACING_CATHODE_ELECTRODE_3

cathode electrode 3 | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730403

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_ELECTRODE

cathode electrode | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730416

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_ELECTRODE_1

cathode electrode 1 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730417

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_ELECTRODE_2

cathode electrode 2 | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730418

MDC_IDC_SET_LEADCHNL_LV_PACING_CATHODE_ELECTRODE_3

cathode electrode 3 | pacing | lead channel left ventricle | setting |

implantable device cardiac | medical device communication

730419

MDC_IDC_SET_LEADCHNL_RA_PACING_CAPTURE_MODE capture mode | pacing | lead channel right atrial | setting | implantable device cardiac | medical device communication

730432

MDC_IDC_ENUM_PACING_CAPTURE_MODE

MDC_IDC_SET_LEADCHNL_RV_PACING_CAPTURE_MODE capture mode | pacing | lead channel right ventricle | setting | implantable device cardiac | medical device communication

730433

MDC_IDC_ENUM_PACING_CAPTURE_MODE

MDC_IDC_SET_LEADCHNL_LA_PACING_CAPTURE_MODE capture mode | pacing | lead channel left atrial | setting | implantable device cardiac | medical device communication

730434

MDC_IDC_ENUM_PACING_CAPTURE_MODE

MDC_IDC_SET_LEADCHNL_LV_PACING_CAPTURE_MODE capture mode | pacing | lead channel left ventricle | setting | implantable device cardiac | medical device communication

730435

MDC_IDC_ENUM_PACING_CAPTURE_MODE

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_LOCATION

anode location | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication

730496

MDC_IDC_ENUM_ELECTRODE_LOCATION

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_LOCATION_1

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

730497

MDC_IDC_ENUM_ELECTRODE_LOCATION

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_LOCATION_2

anode location 2 | vector | shock | lead high voltage

730498

MDC_IDC_ENUM_ELECTRODE_LOCATION

Anexos

101

channel | setting | implantable device cardiac | medical device communication

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_LOCATION_3

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

730499

MDC_IDC_ENUM_ELECTRODE_LOCATION

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ELECTRODE

anode electrode | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication

730560

MDC_IDC_ENUM_ELECTRODE_NAME

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ELECTRODE_1

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

730561

MDC_IDC_ENUM_ELECTRODE_NAME

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ELECTRODE_2

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

730562

MDC_IDC_ENUM_ELECTRODE_NAME

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_ANODE_ELECTRODE_3

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

730563

MDC_IDC_ENUM_ELECTRODE_NAME

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHODE_LOCATION

cathode location | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication

730624

MDC_IDC_ENUM_ELECTRODE_LOCATION

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHODE_LOCATION_1

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

730625

MDC_IDC_ENUM_ELECTRODE_LOCATION

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHODE_LOCATION_2

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

730626

MDC_IDC_ENUM_ELECTRODE_LOCATION

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHODE_LOCATION_3

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

730627

MDC_IDC_ENUM_ELECTRODE_LOCATION

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHODE_ELECTRODE

cathode electrode | vector | shock | lead high voltage channel | setting | implantable device cardiac | medical device communication

730688

MDC_IDC_ENUM_ELECTRODE_NAME

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHODE_ELECTRODE_1

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

730689

MDC_IDC_ENUM_ELECTRODE_NAME

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHODE_ELECTRODE_2

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

730690

MDC_IDC_ENUM_ELECTRODE_NAME

Anexos

102

MDC_IDC_SET_LEADHVCHNL_SHOCK_VECTOR_CATHODE_ELECTRODE_3

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

730691

MDC_IDC_ENUM_ELECTRODE_NAME

MDC_IDC_SET_BRADY_MODE mode | brady | setting | implantable device cardiac | medical device communication

730752

MDC_IDC_ENUM_BRADY_MODE

MDC_IDC_SET_BRADY_VENDOR_MODE mode | brady | setting | implantable device cardiac | medical device communication

730816

MDC_IDC_SET_BRADY_LOWRATE low rate | brady | setting | implantable device cardiac | medical device communication

730880

MDC_IDC_SET_BRADY_HYSTRATE hysteresis rate | brady | setting | implantable device cardiac | medical device communication

730944

MDC_IDC_SET_BRADY_NIGHT_RATE night rate | brady | setting | implantable device cardiac | medical device communication

731008

MDC_IDC_SET_BRADY_SENSOR_TYPE sensor type | brady | setting | implantable device cardiac | medical device communication

731072

MDC_IDC_SET_BRADY_MAX_TRACKING_RATE maximum tracking rate | brady | setting | implantable device cardiac | medical device communication

731136

MDC_IDC_SET_BRADY_MAX_SENSOR_RATE maximum sensor rate | brady | setting | implantable device cardiac | medical device communication

731200

MDC_IDC_SET_BRADY_SAV_DELAY sav delay | brady | setting | implantable device cardiac | medical device communication

731264

MDC_IDC_SET_BRADY_SAV_DELAY_HIGH sav delay high | brady | setting | implantable device cardiac | medical device communication

731265

MDC_IDC_SET_BRADY_SAV_DELAY_LOW sav delay low | brady | setting | implantable device cardiac | medical device communication

731266

MDC_IDC_SET_BRADY_PAV_DELAY pav delay | brady | setting | implantable device cardiac | medical device communication

731328

MDC_IDC_SET_BRADY_PAV_DELAY_HIGH pav delay high | brady | setting | implantable device cardiac | medical device communication

731329

MDC_IDC_SET_BRADY_PAV_DELAY_LOW pav delay low | brady | setting | implantable device cardiac | medical device communication

731330

MDC_IDC_SET_BRADY_AT_MODE_SWITCH_MODE atrial tachy mode switch mode | brady | setting | implantable device cardiac | medical device communication

731392

MDC_IDC_ENUM_BRADY_MODE

MDC_IDC_SET_BRADY_AT_MODE_SWITCH_RATE atrial tachy mode switch rate | brady | setting | implantable device cardiac | medical device communication

731456

MDC_IDC_SET_TACHYTHERAPY_VSTAT ventricular status | tachytherapy | setting |

731520

MDC_IDC_ENUM_THERAPY_STATUS

Anexos

103

implantable device cardiac | medical device communication

MDC_IDC_SET_TACHYTHERAPY_ASTAT atrial status | tachytherapy | setting | implantable device cardiac | medical device communication

731584

MDC_IDC_ENUM_THERAPY_STATUS

MDC_IDC_SET_ZONE_TYPE type | zone | setting | implantable device cardiac | medical device communication

731648

MDC_IDC_ENUM_ZONE_TYPE

MDC_IDC_SET_ZONE_VENDOR_TYPE vendor type | zone | setting | implantable device cardiac | medical device communication

731712

MDC_IDC_SET_ZONE_STATUS status | zone | setting | implantable device cardiac | medical device communication

731776

MDC_IDC_ENUM_ZONE_STATUS

MDC_IDC_SET_ZONE_DETECTION_INTERVAL detection interval | zone | setting | implantable device cardiac | medical device communication

731840

MDC_IDC_SET_ZONE_DETECTION_BEATS_NUMERATOR detection beats numerator | zone | setting | implantable device cardiac | medical device communication

731904

MDC_IDC_SET_ZONE_DETECTION_BEATS_DENOMINATOR

detection beats denominator | zone | setting | implantable device cardiac | medical device communication

731968

MDC_IDC_SET_ZONE_DETECTION_DETAILS detection details | zone | setting | implantable device cardiac | medical device communication

732032

MDC_IDC_SET_ZONE_TYPE_ATP type atrial atrial anti-tachycardia pacing pulse | zone | setting | implantable device cardiac | medical device communication

732096

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_TYPE_ATP_1 type atrial anti-tachycardia pacing pulse 1 | zone | setting | implantable device cardiac | medical device communication

732097

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_TYPE_ATP_2 type atrial anti-tachycardia pacing pulse 2 | zone | setting | implantable device cardiac | medical device communication

732098

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_TYPE_ATP_3 type atrial anti-tachycardia pacing pulse 3 | zone | setting | implantable device cardiac | medical device communication

732099

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_TYPE_ATP_4 type atrial anti-tachycardia pacing pulse 4 | zone | setting | implantable device cardiac | medical device communication

732100

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_TYPE_ATP_5 type atrial anti-tachycardia pacing pulse 5 | zone | setting | implantable device cardiac | medical device communication

732101

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_TYPE_ATP_6 type atrial anti-tachycardia pacing pulse 6 | zone | setting | implantable device cardiac | medical device communication

732102

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_TYPE_ATP_7 type atrial anti-tachycardia pacing pulse 7 | zone | setting | implantable device cardiac | medical

732103

MDC_IDC_ENUM_ATP_TYPE

Anexos

104

device communication

MDC_IDC_SET_ZONE_TYPE_ATP_8 type atrial anti-tachycardia pacing pulse 8 | zone | setting | implantable device cardiac | medical device communication

732104

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_TYPE_ATP_9 type atrial anti-tachycardia pacing pulse 9 | zone | setting | implantable device cardiac | medical device communication

732105

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_TYPE_ATP_10 type atrial anti-tachycardia pacing pulse 10 | zone | setting | implantable device cardiac | medical device communication

732106

MDC_IDC_ENUM_ATP_TYPE

MDC_IDC_SET_ZONE_NUM_ATP_SEQS number of atrial anti-tachycardia pacing pulse sequences | zone | setting | implantable device cardiac | medical device communication

732160

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_1 number of atrial anti-tachycardia pacing pulse sequences 1 | zone | setting | implantable device cardiac | medical device communication

732161

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_2 number of atrial anti-tachycardia pacing pulse sequences 2 | zone | setting | implantable device cardiac | medical device communication

732162

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_3 number of atrial anti-tachycardia pacing pulse sequences 3 | zone | setting | implantable device cardiac | medical device communication

732163

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_4 number of atrial anti-tachycardia pacing pulse sequences 4 | zone | setting | implantable device cardiac | medical device communication

732164

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_5 number of atrial anti-tachycardia pacing pulse sequences 5 | zone | setting | implantable device cardiac | medical device communication

732165

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_6 number of atrial anti-tachycardia pacing pulse sequences 6 | zone | setting | implantable device cardiac | medical device communication

732166

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_7 number of atrial anti-tachycardia pacing pulse sequences 7 | zone | setting | implantable device cardiac | medical device communication

732167

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_8 number of atrial anti-tachycardia pacing pulse sequences 8 | zone | setting | implantable device cardiac | medical device communication

732168

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_9 number of atrial anti-tachycardia pacing pulse sequences 9 | zone | setting | implantable device cardiac | medical device communication

732169

Anexos

105

MDC_IDC_SET_ZONE_NUM_ATP_SEQS_10 number of atrial anti-tachycardia pacing pulse sequences 10 | zone | setting | implantable device cardiac | medical device communication

732170

MDC_IDC_SET_ZONE_SHOCK_ENERGY shock energy | zone | setting | implantable device cardiac | medical device communication

732224

MDC_IDC_SET_ZONE_SHOCK_ENERGY_1 shock energy 1 | zone | setting | implantable device cardiac | medical device communication

732225

MDC_IDC_SET_ZONE_SHOCK_ENERGY_2 shock energy 2 | zone | setting | implantable device cardiac | medical device communication

732226

MDC_IDC_SET_ZONE_SHOCK_ENERGY_3 shock energy 3 | zone | setting | implantable device cardiac | medical device communication

732227

MDC_IDC_SET_ZONE_SHOCK_ENERGY_4 shock energy 4 | zone | setting | implantable device cardiac | medical device communication

732228

MDC_IDC_SET_ZONE_SHOCK_ENERGY_5 shock energy 5 | zone | setting | implantable device cardiac | medical device communication

732229

MDC_IDC_SET_ZONE_SHOCK_ENERGY_6 shock energy 6 | zone | setting | implantable device cardiac | medical device communication

732230

MDC_IDC_SET_ZONE_SHOCK_ENERGY_7 shock energy 7 | zone | setting | implantable device cardiac | medical device communication

732231

MDC_IDC_SET_ZONE_SHOCK_ENERGY_8 shock energy 8 | zone | setting | implantable device cardiac | medical device communication

732232

MDC_IDC_SET_ZONE_SHOCK_ENERGY_9 shock energy 9 | zone | setting | implantable device cardiac | medical device communication

732233

MDC_IDC_SET_ZONE_SHOCK_ENERGY_10 shock energy 10 | zone | setting | implantable device cardiac | medical device communication

732234

MDC_IDC_SET_ZONE_NUM_SHOCKS number of shocks | zone | setting | implantable device cardiac | medical device communication

732288

MDC_IDC_SET_ZONE_NUM_SHOCKS_1 number of shocks 1 | zone | setting | implantable device cardiac | medical device communication

732289

MDC_IDC_SET_ZONE_NUM_SHOCKS_2 number of shocks 2 | zone | setting | implantable device cardiac | medical device communication

732290

MDC_IDC_SET_ZONE_NUM_SHOCKS_3 number of shocks 3 | zone | setting | implantable device cardiac | medical device communication

732291

MDC_IDC_SET_ZONE_NUM_SHOCKS_4 number of shocks 4 | zone | setting | implantable device cardiac | medical device communication

732292

MDC_IDC_SET_ZONE_NUM_SHOCKS_5 number of shocks 5 | zone | setting | implantable device cardiac | medical device communication

732293

MDC_IDC_SET_ZONE_NUM_SHOCKS_6 number of shocks 6 | zone | setting | implantable

732294

Anexos

106

device cardiac | medical device communication

MDC_IDC_SET_ZONE_NUM_SHOCKS_7 number of shocks 7 | zone | setting | implantable device cardiac | medical device communication

732295

MDC_IDC_SET_ZONE_NUM_SHOCKS_8 number of shocks 8 | zone | setting | implantable device cardiac | medical device communication

732296

MDC_IDC_SET_ZONE_NUM_SHOCKS_9 number of shocks 9 | zone | setting | implantable device cardiac | medical device communication

732297

MDC_IDC_SET_ZONE_NUM_SHOCKS_10 number of shocks 10 | zone | setting | implantable device cardiac | medical device communication

732298

MDC_IDC_STAT_DTM date time | statistic | implantable device cardiac | medical device communication

737488

MDC_IDC_STAT_DTM_START date time | statistic | implantable device cardiac | medical device communication start

737489

MDC_IDC_STAT_DTM_END date time | statistic | implantable device cardiac | medical device communication end

737490

MDC_IDC_STAT_HEART_RATE_DTM date time | heart rate | statistic | implantable device cardiac | medical device communication

737616

MDC_IDC_STAT_HEART_RATE_DTM_START date time start | heart rate | statistic | implantable device cardiac | medical device communication

737617

MDC_IDC_STAT_HEART_RATE_DTM_END date time end | heart rate | statistic | implantable

device cardiac | medical device communication

737618

MDC_IDC_STAT_HEART_RATE_ATRIAL atrial | heart rate | statistic | implantable device cardiac | medical device communication

737632

MDC_IDC_STAT_HEART_RATE_ATRIAL_MAX atrial maximum | heart rate | statistic | implantable device cardiac | medical device communication

737633

MDC_IDC_STAT_HEART_RATE_ATRIAL_MIN atrial minimum | heart rate | statistic | implantable device cardiac | medical device communication

737634

MDC_IDC_STAT_HEART_RATE_ATRIAL_MEAN atrial mean | heart rate | statistic | implantable device cardiac | medical device communication

737635

MDC_IDC_STAT_HEART_RATE_VENTRICULAR ventricular | heart rate | statistic | implantable device cardiac | medical device communication

737648

MDC_IDC_STAT_HEART_RATE_VENTRICULAR_MAX ventricular maximum | heart rate | statistic | implantable device cardiac | medical device communication

737649

MDC_IDC_STAT_HEART_RATE_VENTRICULAR_MIN ventricular minimum | heart rate | statistic | implantable device cardiac | medical device communication

737650

MDC_IDC_STAT_HEART_RATE_VENTRICULAR_MEAN ventricular mean | heart rate | statistic | implantable device cardiac | medical device communication

737651

Anexos

107

MDC_IDC_STAT_BRADY_DTM date time | brady | statistic | implantable device cardiac | medical device communication

737504

MDC_IDC_STAT_BRADY_DTM_START date time start | brady | statistic | implantable device cardiac | medical device communication

737505

MDC_IDC_STAT_BRADY_DTM_END date time end | brady | statistic | implantable device cardiac | medical device communication

737506

MDC_IDC_STAT_BRADY_RA_PERCENT_PACED right atrial percent paced | brady | statistic | implantable device cardiac | medical device communication

737520

MDC_IDC_STAT_BRADY_RV_PERCENT_PACED right ventricle percent paced | brady | statistic | implantable device cardiac | medical device communication

737536

MDC_IDC_STAT_BRADY_AP_VP_PERCENT ap-vp percent | brady | statistic | implantable device cardiac | medical device communication

737552

MDC_IDC_STAT_BRADY_AS_VP_PERCENT as-vp percent | brady | statistic | implantable device cardiac | medical device communication

737568

MDC_IDC_STAT_BRADY_AP_VS_PERCENT ap-vs percent | brady | statistic | implantable device cardiac | medical device communication

737584

MDC_IDC_STAT_BRADY_AS_VS_PERCENT as-vs percent | brady | statistic | implantable device cardiac | medical device communication

737600

MDC_IDC_STAT_AT_DTM date time | atrial tachy | statistic | implantable device cardiac | medical device communication

737664

MDC_IDC_STAT_AT_DTM_START date time start | atrial tachy | statistic | implantable device cardiac | medical device communication

737665

MDC_IDC_STAT_AT_DTM_END date time end | atrial tachy | statistic | implantable device cardiac | medical device communication

737666

MDC_IDC_STAT_AT_MODE_SW_MAX_DURATION mode switch maximum duration | atrial tachy | statistic | implantable device cardiac | medical device communication

737680

MDC_IDC_STAT_AT_BURDEN_PERCENT burden percent | atrial tachy | statistic | implantable device cardiac | medical device communication

737696

MDC_IDC_STAT_AT_MODE_SW_PERCENT_TIME mode switch percent of time | atrial tachy | statistic | implantable device cardiac | medical device communication

737712

MDC_IDC_STAT_AT_MODE_SW_PERCENT_TIME_PER_DAY

mode switch percent of time per day | atrial tachy | statistic | implantable device cardiac | medical device communication

737728

MDC_IDC_STAT_AT_MODE_SW_COUNT mode switch count | atrial tachy | statistic | implantable device cardiac | medical device communication

737744

MDC_IDC_STAT_AT_MODE_SW_COUNT_PER_DAY mode switch count per day 73776

Anexos

108

| atrial tachy | statistic | implantable device cardiac | medical device communication

0

MDC_IDC_STAT_CRT_DTM date time | cardiac resynchronization therapy | statistic | implantable device cardiac | medical device communication

737776

MDC_IDC_STAT_CRT_DTM_START date time | cardiac resynchronization therapy | statistic | implantable device cardiac | medical device communication start

737777

MDC_IDC_STAT_CRT_DTM_END date time | cardiac resynchronization therapy | statistic | implantable device cardiac | medical device communication end

737778

MDC_IDC_STAT_CRT_LV_PERCENT_PACED left ventricle percent paced | cardiac resynchronization therapy | statistic | implantable device cardiac | medical device communication

737792

MDC_IDC_STAT_CRT_PERCENT_PACED percent paced | cardiac resynchronization therapy | statistic | implantable device cardiac | medical device communication

737808

MDC_IDC_STAT_TACHYTHERAPY_SHOCKS_DELIVERED_RECENT

recent shocks delivered | tachy therapy | statistic | implantable device cardiac | medical device communication

737824

MDC_IDC_STAT_TACHYTHERAPY_SHOCKS_DELIVERED_TOTAL

total shocks delivered | tachy therapy | statistic | implantable device cardiac | medical device

communication

737840

MDC_IDC_STAT_TACHYTHERAPY_SHOCKS_ABORTED_RECENT

recent shocks aborted | tachy therapy | statistic | implantable device cardiac | medical device communication

737856

MDC_IDC_STAT_TACHYTHERAPY_SHOCKS_ABORTED_TOTAL

total shocks aborted | tachy therapy | statistic | implantable device cardiac | medical device communication

737872

MDC_IDC_STAT_TACHYTHERAPY_ATP_DELIVERED_RECENT

recent atrial anti-tachycardia pacing delivered | tachy therapy | statistic | implantable device cardiac | medical device communication

737888

MDC_IDC_STAT_TACHYHERAPY_ATP_DELIVERED_TOTAL

total atrial anti-tachycardia pacing delivered | tachy therapy | statistic | implantable device cardiac | medical device communication

737904

MDC_IDC_STAT_TACHYHERAPY_TOTAL_DTM date time | total | tachy therapy | statistic | implantable device cardiac | medical device communication

737920

MDC_IDC_STAT_TACHYHERAPY_TOTAL_DTM_START date time start | total | tachy therapy | statistic | implantable device cardiac | medical device communication

737921

MDC_IDC_STAT_TACHYHERAPY_TOTAL_DTM_END date time end | total | tachy therapy | statistic | implantable device cardiac | medical device

737922

Anexos

109

communication

MDC_IDC_STAT_TACHYTHERAPY_RECENT_DTM date time | recent | tachy therapy | statistic | implantable device cardiac | medical device communication

737936

MDC_IDC_STAT_TACHYTHERAPY_RECENT_DTM_START date time start | recent | tachy therapy | statistic | implantable device cardiac | medical device communication

737937

MDC_IDC_STAT_TACHYTHERAPY_RECENT_DTM_END date time end | recent | tachy therapy | statistic | implantable device cardiac | medical device communication

737938

MDC_IDC_STAT_EPISODE_TYPE type | episode | statistic | implantable device cardiac | medical device communication

737952

MDC_IDC_ENUM_EPISODE_TYPE

MDC_IDC_STAT_EPISODE_TYPE_INDUCED type induced | episode | statistic | implantable device cardiac | medical device communication

737968

MDC_IDC_ENUM_EPISODE_TYPE_INDUCED

MDC_IDC_STAT_EPISODE_VENDOR_TYPE vendor type | episode | statistic | implantable device cardiac | medical device communication

737984

MDC_IDC_STAT_EPISODE_RECENT_COUNT recent count | episode | statistic | implantable device cardiac | medical device communication

738000

MDC_IDC_STAT_EPISODE_RECENT_COUNT_DTM date time | recent | episode | statistic | implantable device cardiac | medical device communication

738016

MDC_IDC_STAT_EPISODE_RECENT_COUNT_DTM_START date time start | recent | episode | statistic | implantable device cardiac | medical device communication

738017

MDC_IDC_STAT_EPISODE_RECENT_COUNT_DTM_END date time end | recent | episode | statistic | implantable device cardiac | medical device communication

738018

MDC_IDC_STAT_EPISODE_TOTAL_COUNT total count | episode | statistic | implantable device cardiac | medical device communication

738032

MDC_IDC_STAT_EPISODE_TOTAL_COUNT_DTM date time | total | episode | statistic | implantable device cardiac | medical device communication

738048

MDC_IDC_STAT_EPISODE_TOTAL_COUNT_DTM_START date time start | total | episode | statistic | implantable device cardiac | medical device communication

738049

MDC_IDC_STAT_EPISODE_TOTAL_COUNT_DTM_END date time end | total | episode | statistic | implantable device cardiac | medical device communication

738050

MDC_IDC_EPISODE_ID identifier | episode | implantable device cardiac | medical device communication

739536

MDC_IDC_EPISODE_DTM date time | episode | implantable device cardiac | medical device communication

739552

MDC_IDC_EPISODE_TYPE type | episode | implantable device cardiac | medical device

739568

MDC_IDC_ENUM_EPISODE_TYPE

Anexos

110

communication

MDC_IDC_EPISODE_TYPE_INDUCED type induced | episode | implantable device cardiac | medical device communication

739584

MDC_IDC_ENUM_EPISODE_TYPE_INDUCED

MDC_IDC_EPISODE_VENDOR_TYPE vendor type | episode | implantable device cardiac | medical device communication

739600

MDC_IDC_EPISODE_ATRIAL_INTERVAL_AT_DETECTION atrial interval at detection | episode | implantable device cardiac | medical device communication

739616

MDC_IDC_EPISODE_ATRIAL_INTERVAL_AT_TERMINATION

atrial interval at termination | episode | implantable device cardiac | medical device communication

739632

MDC_IDC_EPISODE_VENTRICULAR_INTERVAL_AT_DETECTION

ventricular interval at detection | episode | implantable device cardiac | medical device communication

739648

MDC_IDC_EPISODE_VENTRICULAR_INTERVAL_AT_TERMINATION

ventricular interval at termination | episode | implantable device cardiac | medical device communication

739664

MDC_IDC_EPISODE_DETECTION_THERAPY_DETAILS detection therapy details | episode | implantable device cardiac | medical device communication

739680

MDC_IDC_EPISODE_THERAPY_RESULT therapy result | episode | implantable device cardiac | medical device communication

739696

MDC_IDC_ENUM_EPISODE_THERAPY_RESULT

MDC_IDC_EPISODE_DURATION duration | episode | implantable device cardiac | medical device communication

739712

Anexos

111

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">

Anexos

112

<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">

Anexos

113

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

Anexos

114

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

Anexos

115

<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.testsystem-homemonitoring.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>

Anexos

116

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

Anexos

117

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

Anexos

118

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()))

Anexos

119

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

Anexos

120

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

Anexos

121

--- 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)

Anexos

122

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"))

Anexos

123

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

Anexos

124

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

Anexos

125

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

Anexos

126

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

Anexos

127

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()

Anexos

128

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_MSMT,MDC_IDC_PG_TYPE_SET,MDC_IDC_PG_TYPE_STAT,MDC_ATTR_PT,BIO }

Anexos

129

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

Anexos

130

Mensaje final generado por el actor DOR.

MSH|^~\&|BioHMSC|Biotronik|RPM|any clinic|201203170127||ORU^R01|6FDA634FAB035E97540F3A12E97784B7|D|2.6| PID|||MODEL:LUMAX 300 VR-T/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|||20100903180102+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+0200| 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+0200| OBX|22|CWE|754178^MDC_IDC_MSMT_CAP_CHARGE_TYPE^MDC||Reformation||||||F|||20100903180102+0200| 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|||20100903180102+0200| OBX|26|NM|722433^MDC_IDC_MSMT_LEADCHNL_RV_IMPEDANCE_VALUE^MDC||440|Ohm^UCUM|||||F|||20100903180102+0200| OBX|27|CWE|754306^MDC_IDC_MSMT_LEADCHNL_RV_IMPEDANCE_POLARITY^MDC||BI||||||F|||20100903180102+0200| OBX|28|DTM|721926^MDC_IDC_MSMT_LEADCHNL_RV_DTM_END^MDC||20100801015536||||||F|||20100903180102+0200| OBX|29|CWE|754242^MDC_IDC_MSMT_LEADCHNL_RV_LEAD_CHANNEL_STATUS^MDC||Null||||||F|||20100903180102+0200| OBX|30|DTM|722562^MDC_IDC_MSMT_LEADHVCHNL_DTM_END^MDC||20100801015536||||||F|||20100903180102+0200| OBX|31|NM|722624^MDC_IDC_MSMT_LEADHVCHNL_IMPEDANCE^MDC||52|Ohm^UCUM|||||F|||20100903180102+0200| OBX|32|CWE|754433^MDC_IDC_MSMT_LEADHVCHNL_MEASUREMENT_TYPE^MDC||LowVoltage||||||F|||20100903180102+0200| OBX|33|CWE|754242^MDC_IDC_MSMT_LEADHVCHNL_STATUS^MDC||Null||||||F|||20100903180102+0200|

Anexos

131

OBX|34|DTM|722562^MDC_IDC_MSMT_LEADHVCHNL_DTM_END^MDC||20100226164630||||||F|||20100903180102+0200| OBX|35|NM|722624^MDC_IDC_MSMT_LEADHVCHNL_IMPEDANCE^MDC||28|Ohm^UCUM|||||F|||20100903180102+0200| OBX|36|CWE|754434^MDC_IDC_MSMT_LEADHVCHNL_MEASUREMENT_TYPE^MDC||Shock||||||F|||20100903180102+0200| OBX|37|CWE|754241^MDC_IDC_MSMT_LEADHVCHNL_STATUS^MDC||CheckLead||||||F|||20100903180102+0200| 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|||20100903180102+0200| OBX|41|CWE|754561^MDC_IDC_SET_LEADCHNL_RV_SENSING_ANODE_ELECTRODE_1^MDC||Tip||||||F|||20100903180102+0200| OBX|42|CWE|754498^MDC_IDC_SET_LEADCHNL_RV_SENSING_CATHODE_LOCATION_1^MDC||RV||||||F|||20100903180102+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||AdaptiveSensing||||||F|||20100903180102+0200| OBX|45|NM|729985^MDC_IDC_SET_LEADCHNL_RV_PACING_AMPLITUDE^MDC||4.0|V^UCUM|||||F|||20100903180102+0200| OBX|46|NM|730049^MDC_IDC_SET_LEADCHNL_RV_PACING_PULSEWIDTH^MDC||1.0|ms^UCUM|||||F|||20100903180102+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|||20100903180102+0200| OBX|49|CWE|754561^MDC_IDC_SET_LEADCHNL_RV_PACING_ANODE_ELECTRODE_1^MDC||Tip||||||F|||20100903180102+0200| OBX|50|CWE|754498^MDC_IDC_SET_LEADCHNL_RV_PACING_CATHODE_LOCATION_1^MDC||RV||||||F|||20100903180102+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+0200| 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||BIO-Zone_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|||20100903180102+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+0200| OBX|65|NM|732225^MDC_IDC_SET_ZONE_SHOCK_ENERGY_1^MDC||30|J^UCUM|||||F|||20100903180102+0200| OBX|66|NM|732226^MDC_IDC_SET_ZONE_SHOCK_ENERGY_2^MDC||30|J^UCUM|||||F|||20100903180102+0200| OBX|67|NM|732291^MDC_IDC_SET_ZONE_NUM_SHOCKS_3^MDC||6|{shocks}^UCUM|||||F|||20100903180102+0200|

Anexos

132

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||BIO-Zone_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||BIO-Zone_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|||20100903180102+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+0200| OBX|79|NM|737536^MDC_IDC_STAT_BRADY_RV_PERCENT_PACED^MDC||10|%|||||F|||20100903180102+0200| 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}^UCUM|||||F|||20100903180102+0200 OBX|83|NM|737872^MDC_IDC_STAT_TACHYTHERAPY_SHOCKS_ABORTED_TOTAL^MDC||9|{shocks}^UCUM|||||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|||20100903180102+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||BIO-Epis_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|||20100903180102+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||BIO-Epis_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|||20100903180102+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||BIO-Epis_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||BIO-Epis_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|

Lista de Figuras

133

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

Lista de Tablas

134

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

Bibliografía

135

8. Bibliografía

1 http://www.texasheartinstitute.org/HIC/anatomy_Esp/anato_sp.cfm

2 http://masquecorazon.com/anatomiacorazon.html

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

4 http://www.yalemedicalgroup.org/stw/Page.asp?PageID=STW027669.

5 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

6 http://www.ate.uniovi.es/8695/documentos/TRABAJOS%202008/avances/viernes%2016-01-09%20bio/10-30/G5%20El%20marcapasos.pdf

7 http://www.biotronik.com/biohm/the-new-biotronik-home-monitoring/18593

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

9 http://www.ihe-europe.net/drupal/sites/default/files/IHE_Basics_SP.pdf

10 http://www.ihe-e.org/intro.htm

11 http://www.ihe.net/Technical_Framework/upload/IHE_PCD_TF_Vol2_FT_2011-08-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