Integración automática de datos de un marca pasos a un sistema gestor de historia clínica...
-
Upload
alvaro-cortes-manica -
Category
Documents
-
view
943 -
download
6
description
Transcript of Integración automática de datos de un marca pasos a un sistema gestor de historia clínica...
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
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
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