Importación de datos TAB y XML Acerca de las importaciones de TAB y XML El programa CoPilot Health Management System ofrece funciones para importar y exportar datos en los dos formatos siguientes: 1. TAB: texto delimitado por tabuladores 2. XML: lenguaje de marcado extensible Estos formatos se utilizan dentro del programa para archivar datos, pero también sirven para importar datos de orígenes externos que, de lo contrario, no serían compatibles con el programa CoPilot. Posibilidades de importación Las funciones de importación del programa CoPilot se limitan a los siguientes tipos de datos de eventos: Ejercicio Glucosa Insulina basal Insulina de bolo Resultados de laboratorio Comida Examen médico Medicamento Notas Estado de salud Lecturas de cetona Alarmas Eventos genéricos Habilidades necesarias El usuario debe tener la destreza técnica necesaria para manipular o crear archivos de datos según lo descrito en este documento. La importación de estos archivos no debe ser realizada por usuarios que no comprendan plenamente los requisitos de formato. Precaución: Antes de importar datos en CoPilot, el usuario debe comprobar que tienen el formato adecuado. Formatos de los archivos A fin de simplificar la documentación y proporcionar los conocimientos básicos sobre la función de importación, este documento se concentra en el formato de los datos cuando se importan archivos TAB. Existen muchas similaridades entre los requisitos de formato de los archivos TAB y XML. Al final de este documento, en la sección Normas XML, se detallan los requisitos específicos del formato XML. DOC14018 Rev. A 03/08 1 Importación de datos TAB y XML Existen numerosos métodos disponibles para crear archivos de importación TAB que sean aceptables para CoPilot. En la mayor parte de la información a modo de ejemplo de este documento, se supone que el usuario elabora los archivos de importación en Excel. A continuación se describen las dos limitaciones que presenta el uso de Excel: 1. En algunas circunstancias, Microsoft Excel puede agregar comillas no válidas al texto de los campos cuando se guardan los archivos. Esto ocurre si los datos contienen comas u otros caracteres delimitadores habituales. El usuario debe eliminar esas comillas antes de importar los archivos en CoPilot. 2. Para evitar discrepancias en los valores numéricos y temporales, al convertir entre Microsoft Excel y CoPilot es necesario que todos los valores se traten en Microsoft Excel con precisión doble completa. La forma de conseguir esto en Microsoft Excel es asignar al menos 10 espacios decimales al formato de las unidades de esos números. Estructura de los archivos Un archivo TAB para importación en CoPilot debe ser un archivo de texto ASCII sin formato compuesto por registros dispuestos en filas. Cada fila constituye la entrada completa de un solo evento de datos. Cada fila está formada por varios campos de datos definidos separados por un carácter de tabulador (ASCII 09). Asimismo, cada fila termina con un carácter ASCII de retorno de carro o salto de línea. Tipo de archivo Los nombres de los archivos de importación TAB deben tener la extensión .TAB. Los nombres de los archivos de importación XML deben tener la extensión .XML. DOC14018 Rev. A 03/08 2 Importación de datos TAB y XML Títulos Los archivos de importación deben tener títulos en su primera línea. Los títulos deben incluir todas las etiquetas de campo siguientes, tal como se presentan a continuación, y deben estar separadas por tabuladores: DATEEVENT TIMESLOT EVENTTYPE DEVICE_MODEL DEVICE_ID VENDOR_EVENT_TYPE_ID VENDOR_EVENT_ID KEY0 KEY1 KEY2 I0 I1 I2 I3 I4 I5 I6 I7 I8 I9 D0 D1 D2 D3 D4 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 ISMANUAL COMMENT DELETED DOC14018 Rev. A 03/08 3 Importación de datos TAB y XML Filas de datos Cada una de las filas que siguen los títulos deben contener datos que se correspondan con los campos existentes en la cabecera. En algunos casos los campos pueden estar vacíos, pero su posición debe estar marcada por el tabulador correspondiente. Campos de datos En cada fila de datos hay dos tipos diferentes de campos: campos de datos constantes y campos de datos que dependen del tipo de evento. Todos los valores de los campos son texto de caracteres ASCII, pero algunos campos tienen que ser numéricos (formados por cifras que puedan interpretarse como números enteros o de punto flotante). CoPilot maneja el formato y el ajuste del texto, por lo que no es necesario (ni aconsejable) incluir retornos ni saltos de línea dentro de los campos de texto. Los campos “C” (C1, C2, C3, etc.) que no se usen pueden dejarse vacíos. Los campos “I” o “D” (I0, I1, D2, etc.) que no se usen deben establecerse con el número cero. Campos de datos constantes Los siguientes campos se relacionan con todos los registros de datos y su formato es uniforme, sea cual sea el tipo de evento. DATEEVENT El campo DATEEVENT contiene la fecha y la hora del evento registrado. El campo contiene un número de punto flotante con doble precisión que puede convertirse en una fecha compatible con Microsoft Windows. Por convención, la parte entera representa el número de días transcurridos desde la fecha inicial establecida. En este caso, la fecha inicial, que corresponde a un valor de cero, es el 30 de diciembre de 1899 a las 12:00 AM. La parte fraccionaria de un valor de fecha representa la parte del día que ha transcurrido. Ejemplo: 0.5 corresponde a las 12:00:00 PM del 30 de diciembre de 1899. TIMESLOT La mayoría de los datos introducidos en CoPilot se asocian con un período de tiempo o franja horaria. Los valores introducidos en este campo deben ser números enteros, de acuerdo con el siguiente esquema: Antes del desayuno = 0 Después del desayuno = 1 Antes del almuerzo = 2 Después del almuerzo = 3 Antes de la cena = 4 Después de la cena = 5 Antes de ir a dormir = 6 Durante la noche = 7 Para que CoPilot introduzca una franja horaria en función de los períodos de tiempo preferidos por el usuario para la hora del evento dado, establezca -1 como valor de TIMESLOT. Para obtener más información sobre la asignación de valores de TIMESLOT, consulte la sección Comida EVENTTYPE. DOC14018 Rev. A 03/08 4 Importación de datos TAB y XML EVENTTYPE Los tipos de eventos se introducen como números enteros de acuerdo con el siguiente esquema: Ejercicio = 0 Glucosa = 1 Insulina basal = 2 Insulina de bolo = 3 Resultados de laboratorio = 4 Comida = 5 Examen médico = 6 Medicamentos = 7 Notas = 8 Estado de salud = 9 Cetona = 10 Alarmas = 15 Eventos genéricos = 16 Nota: Los tipos de eventos 11, 12, 13 y 14 están reservados. DEVICE_MODEL El campo DEVICE_MODEL tiene un tipo de datos de cadena y una longitud máxima de 64 caracteres. Este campo debe contener el nombre (descripción) del dispositivo en el que se generaron los datos importados. Si un archivo de importación se prepara con datos procedentes de un origen que también puede haberse cargado o importado directamente en CoPilot, la descripción debe coincidir exactamente con la utilizada en CoPilot. De lo contrario, se limita la capacidad de CoPilot para filtrar registros mediante este dato. Cuando se elaboran varios archivos de importación con datos procedentes del mismo dispositivo, debe prestarse atención a que su DEVICE_MODEL sea idéntico en cada archivo. En los filtros definidos por DEVICE_MODEL se distingue entre mayúsculas y minúsculas. Para que todos los datos se importen correctamente en CoPilot, este campo debe estar llenado. DEVICE_ID El campo DEVICE_ID tiene un tipo de datos de cadena y una longitud máxima de 64 caracteres. Este campo debe contener la identificación exclusiva específica (normalmente el número de serie) del dispositivo en el que se generaron los datos importados. Si un archivo de importación se prepara con datos procedentes de un origen que también puede haberse cargado o importado directamente en CoPilot, el valor de DEVICE_ID debe coincidir exactamente con la identificación utilizada en CoPilot. De lo contrario, se limita la capacidad de CoPilot para filtrar registros mediante este dato. Cuando se elaboran varios archivos de importación con datos procedentes del mismo dispositivo, debe prestarse atención a que su DEVICE_ID sea idéntico en cada archivo. En los filtros definidos por DEVICE_ID se distingue entre mayúsculas y minúsculas. Para que todos los datos se importen correctamente en CoPilot, este campo debe estar llenado. DOC14018 Rev. A 03/08 5 Importación de datos TAB y XML VENDOR_EVENT_TYPE_ID VENDOR_EVENT_TYPE_ID es un campo de número entero que se utiliza internamente para diferenciar entre distintas clases de identificadores de eventos. Para todos los eventos de CoPilot descritos en este documento, este campo debe llenarse con el número cero. VENDOR_EVENT_ID El campo VENDOR_EVENT_ID tiene un tipo de datos de cadena y una longitud máxima de 64 caracteres. Si este campo no se utiliza, hay que dejarlo vacío. El campo VENDOR_EVENT_ID ayuda a CoPilot a identificar y manejar los registros de eventos duplicados. Si el dispositivo o el origen desde los que se importan los datos contienen un identificador de registros único y no repetitivo, este campo puede utilizarse para evitar importar varias copias del mismo registro de un evento desde un dispositivo. Para buscar y definir registros duplicados, CoPilot combina el campo VENDOR_EVENT_ID con su identificación exclusiva del usuario, el campo DEVICE_MODEL y el campo DEVICE_ID. KEY0, KEY1, KEY2 Los campos KEY0, KEY1 y KEY2 buscan y rechazan los eventos duplicados que CoPilot guarda. Cada uno de estos campos contiene un número entero; la comparación para buscar duplicados se basa en la combinación de la identificación de usuario, DATEEVENT, EVENTTYPE y la adición de los tres campos KEY. En general estos campos describen el “valor” del registro del evento. Para que un evento se guarde en la base de datos de CoPilot, el valor de KEY debe estar llenado y ser exclusivo para ese EVENTTYPE en la base de datos. Para que CoPilot busque y rechace correctamente los eventos duplicados, estos campos deben estar llenados. Nota: La lógica anterior se aplica de forma estricta para la evaluación de duplicados. Si no llena los campos KEY (establecerlos en cero), todos los registros de eventos posteriores que tengan valores idénticos para usuario, DATEEVENT y EVENTTYPE, se rechazarán por considerarse duplicados. Por otra parte, si llena los tres campos KEY con números enteros grandes aleatorios (que es improbable que se repitan), se guardarán todos los registros, sin importar su similitud con otros registros de la base de datos. ISMANUAL El campo ISMANUAL indica si los datos originales proceden de un dispositivo o se han introducido a mano. En CoPilot este campo determina si la información de hora, fecha o valor puede ser modificada por el usuario de CoPilot. ISMANUAL = 1 indica que los datos se introdujeron manualmente (debería permitirse su modificación). ISMANUAL = 0 indica que los datos se cargaron desde un dispositivo (no debería permitirse su modificación). Nota: CoPilot sólo permite este tipo de modificación con los datos introducidos a mano. DOC14018 Rev. A 03/08 6 Importación de datos TAB y XML COMMENT COMMENT es un campo opcional de texto libre que puede contener un máximo de 250 caracteres. DELETED DELETED = 0 significa que el registro del evento en CoPilot se incluye en los cálculos estadísticos y en las vistas de los informes. DELETED = 1 significa que el registro del evento se oculta en CoPilot y se excluye de los cálculos estadísticos y de las vistas de los informes. Campos de datos que dependen del tipo de evento En esta sección se describe cómo llenar los campos I0-I9, D0-D4 y C0-C9 para cada tipo de evento (EVENTTYPE). Sus descripciones incluyen los datos requeridos para cada campo. Los campos que se muestran vacíos en la tabla deben llenarse con ceros cuando son campos “I” y “D” (tipos numéricos) y pueden dejarse vacíos si se trata de campos “C”. Los campos “I” contienen valores numéricos que pueden representarse como números enteros; los “D” son números que corresponden a valores de punto flotante con doble precisión; y los campos “C” son cadenas de un máximo de 250 caracteres imprimibles. Esta sección también describe los campos KEY0, KEY1 y KEY2 que deben estar llenados en el programa CoPilot para poder introducir datos. En algunos casos, estos valores KEY pueden crearse generando números enteros a partir de valores de cadena por medio del algoritmo ElfHash. Para ver una versión en Pascal del código de este algoritmo, consulte la sección ElfHash al final de este documento. Nota: Para importar archivos de datos, no es obligatorio seguir las mismas convenciones de KEY duplicadas que CoPilot utiliza, pero la convención empleada tiene que proporcionar amplias capacidades de detección y rechazo de entradas duplicadas. DOC14018 Rev. A 03/08 7 Importación de datos TAB y XML Ejercicio {EVENTTYPE = 0}: El tipo de evento Ejercicio está previsto para su uso con datos de ejercicios, de la siguiente forma: Campo KEY0 KEY1 KEY2 I0 I1 I2 I3 I4 I5 I6 I7 I8 I9 D0 D1 D2 D3 D4 C0 Datos contenidos ElfHash( Duración ) ElfHash( Tipo de ejercicio ) ElfHash( Intensidad ) Notas sobre la implementación Tipo de ejercicio C1 Duración C2 Intensidad Texto libre que describe el tipo de ejercicio que se documenta. Texto libre que describe la duración del ejercicio, normalmente expresada en horas. Texto libre que describe la intensidad del ejercicio, normalmente Baja, Media o Alta. C3 C4 C5 C6 C7 C8 C9 DOC14018 Rev. A 03/08 8 Importación de datos TAB y XML Glucosa {EVENTTYPE = 1}: El tipo de evento Glucosa se ha diseñado para su uso con datos de glucosa, de la siguiente forma: Campo Datos contenidos KEY0 Valor de glucosa KEY1 KEY2 I0 Marca de control I1 I2 Valor de glucosa Marca de fuera del rango I3 Horas desde la última comida I4 Marca de temperatura I5 Marca de MC DOC14018 Rev. A 03/08 Notas sobre la implementación Glucosa en mg/dL. 0 = Sin valor de control. 1 = Valor de control. Expresado en mg/dL. -1 = Bajo (1 negativo). 0 = Dentro del rango. 1 = Alto. Valor = Horas:Minutos. 0 = 0:00 1 = 0:15 2 = 0:30 3 = 0:45 4 = 1:00 5 = 1:30 6 = 2:00 7 = 2:30 8 = 3:00 9 = 3:30 10 = 4:00 11 => 4:00. (Opcional) 0 = Dentro del rango de temperatura. 1 = Fuera del rango de temperatura. Nota: Si esta marca está establecida (campo = 1), el evento de glucosa seguirá apareciendo en el informe Lista diaria de CoPilot, pero no se mostrará en otros informes de CoPilot ni en los cálculos estadísticos. 0 = Valores discretos de la glucosa medida. 1 = Datos de glucosa obtenidos de un dispositivo de medición continua, como FreeStyle Navigator. 9 Importación de datos TAB y XML I6 I7 I8 I9 D0 D1 D2 D3 D4 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 Tendencia Indica la tendencia de los datos continuos de glucosa con respecto a la medida actual, de la siguiente forma: 0 = Sin símbolo 1 = Símbolo de flecha hacia arriba 2 = Símbolo de flecha oblicua hacia arriba 3 = Símbolo de flecha horizontal 4 = Símbolo de flecha oblicua hacia abajo 5 = Símbolo de flecha hacia abajo Nota: Este campo no se tiene en cuenta a menos que I5 = 1. Sitio de muestra Código de calibración Estado del dispositivo Texto libre. (Opcional) Texto libre. (Opcional) Texto libre. (Opcional) Insulina basal {EVENTTYPE = 2}: El tipo de evento Insulina basal está destinado a su uso únicamente con datos de insulina basal bombeada. Para que el programa reconozca correctamente los eventos de insulina basal de un día dado, éstos deben tener también un registro de insulina basal que indique el total de insulina basal bombeada durante el día (I0 = 2, D1 = total de unidades de insulina basal bombeada durante el día de 24 horas). Los perfiles de insulina basal se crean mediante una serie de eventos de insulina basal, cada uno de los cuales describe la velocidad de una nueva administración que se inicia a una hora determinada. La administración de insulina se termina con un evento que tiene un valor de velocidad basal (D0) cero. Campo Datos contenidos KEY0 Orden de insulina basal KEY1 Trunc(Velocidad*1000) DOC14018 Rev. A 03/08 Notas sobre la implementación Véase I1. La tasa basal o campo de “valor”. El valor se trunca después de multiplicar la tasa por 1000. 10 Importación de datos TAB y XML KEY2 I0 Tipo de insulina basal Tipo de insulina basal I1 Orden de insulina basal I2 I3 I4 I5 I6 I7 I8 I9 D0 Velocidad D1 Total bombeado D2 D3 D4 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 Nombre del perfil Descripción DOC14018 Rev. A 03/08 Véase I0. 0 = Programado. 1 = Temporal. 2 = Total bombeado hoy. Cuando se registran varios eventos de insulina basal en el mismo minuto, este valor denota el orden secuencial apropiado de los eventos. Esto puede ser muy importante, por ejemplo, en los casos en los que se detienen e inician segmentos basales en el mismo minuto y resulta importante saber qué evento ocurrió en primer lugar. El campo de Orden de insulina basal contiene un número entero que indica el orden de los eventos dentro de ese minuto, correspondiendo el valor más bajo al evento que sucedió en primer lugar. Unidades por hora. Nota: Los eventos de insulina basal se introducen en forma de velocidad. Total de unidades bombeadas hoy. (No se tiene en cuenta a menos que I0 = 2). No se utiliza actualmente; debería estar vacío. Texto libre. 11 Importación de datos TAB y XML Insulina de bolo {EVENTTYPE = 3}: El tipo de evento Insulina de bolo sólo está indicado para su uso con datos de insulina de bolo bombeada. Para que el programa reconozca correctamente los eventos de bolo de insulina bombeada de un día dado, éstos deben tener también un registro de insulina de bolo correspondiente que indique el total de insulina de bolo de ese tipo (corrección o comida) bombeada durante el día (I0 = 3 ó 4, D1 = total de unidades de insulina de bolo de ese tipo bombeada durante el día de 24 horas). Campo Datos contenidos KEY0 Tipo de insulina de bolo KEY1 Trunc(Dosificación*1000) Notas sobre la implementación El valor se trunca después de multiplicar la dosificación por 1000. KEY2 I0 Tipo de insulina de bolo 0 = Comida. 1 = Corrección. 2 = General. 3 = Total de insulina de bolo de corrección bombeado hoy. 4 = Total de insulina de bolo de comida bombeado hoy. Nota: Los eventos individuales de insulina de bolo bombeado deberían usar siempre Tipo de insulina de bolo = 0 ó 1. Los eventos de insulina de bolo manual deberían usar siempre Tipo de insulina de bolo = 0 ó 1 ó 2. I1 I2 I3 I4 I5 I6 I7 I8 I9 D0 Dosificación D1 Total bombeado Insulina de bolo administrada, expresada en unidades de insulina. Total de insulina de bolo bombeada hoy, expresado en unidades de insulina. No se tiene en cuenta a menos que I0 = 3 ó 4. D2 D3 D4 C0 C1 Nombre de insulina Tipo de insulina de bolo C2 Descripción DOC14018 Rev. A 03/08 Texto libre. Texto libre. (Caracterizaciones, como onda cuadrada, combinación, inyección, etc.) (Opcional) Texto libre. (Información general sobre la administración de insulina.) (Opcional) 12 Importación de datos TAB y XML C3 C4 C5 C6 C7 C8 C9 Resultados de laboratorio {EVENTTYPE = 4}: El tipo de evento Resultados de laboratorio está diseñado para informar sobre los resultados de las pruebas de laboratorio. Utilice los nombres de las pruebas con uniformidad puesto que la función de informe cotejará y ordenará los resultados de laboratorio por el tipo de prueba. Campo KEY0 KEY1 KEY2 I0 I1 I2 I3 I4 I5 I6 I7 I8 I9 D0 D1 D2 D3 D4 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 Datos contenidos ElfHash(Valor de resultado) ElfHash(Tipo de prueba) ElfHash(Rango de referencia + Unidades) Notas sobre la implementación Rango de referencia Rango de referencia asignado por el laboratorio a este resultado. (Opcional) Resultado del que se informa para esta prueba. Nombre o descripción de la prueba. Unidades de medida del resultado. Valor de resultado Tipo de prueba Unidades DOC14018 Rev. A 03/08 13 Importación de datos TAB y XML Comida {EVENTTYPE = 5}: El tipo de evento Comida está indicado para informar sobre los datos de las comidas. El tipo de evento Comida utiliza el campo TIMESLOT de forma distinta a otros eventos. El campo TIMESLOT debe llenarse dependiendo de la comida, de esta forma: 0 = Desayuno, 1 = Almuerzo, 2 = Cena, 3 = Merienda. Si el campo TIMESLOT está establecido en -1, CoPilot calculará la categoría de la comida en función de las preferencias del usuario en cuanto a los períodos de tiempo. Campo KEY0 Datos contenidos Trunc(Carbohidratos*1000) KEY1 ElfHash(FloatToStr(Calorías) + ‘ ‘ + FloatToStr(Proteínas) + ‘ ‘ + FloatToStr(Grasas) ) ElfHash(Descripción0 + Descripción1 + Descripción2 + … + Descripción7) KEY2 I0 I1 I2 I3 I4 I5 I6 I7 I8 I9 D0 D1 Calorías Carbohidratos D2 D3 D4 C0 C1 C2 C3 C4 C5 C6 C7 C8 Grasas Proteínas C9 Otra información Descripción0 Descripción1 Descripción2 Descripción3 Descripción4 Descripción5 Descripción6 Descripción7 Categoría de comida DOC14018 Rev. A 03/08 Notas sobre la implementación El valor se trunca después de multiplicar los carbohidratos por 1000. No se utiliza. Total de carbohidratos de la comida, expresado en gramos. No se utiliza. No se utiliza. Véase la nota más abajo. Este campo es para uso interno de CoPilot. Déjelo vacío. Texto libre. 14 Importación de datos TAB y XML Nota: Los campos Descripción almacenan descripciones (de tipo cadena) de los datos relacionados con la comida, con el siguiente formato: X|Y|Z, donde: X = número de raciones. Y = número de gramos de carbohidratos por ración. Z = descripción del alimento (N/A si no está disponible). Si la comida incluye varios alimentos, esas cadenas se concatenan y se separan por un carácter de circunflejo (ASCII 94): X|Y|Z^X|Y|Z^X|Y|Z^X|Y|Z Observe que los separadores “|” y “^” (barra vertical y circunflejo) son caracteres reservados y no pueden aparecer en los datos. En el caso más simple, en que no están disponibles las descripciones de los alimentos, una comida de 15 g se representa así: 1|15|N/A (Éste también es un caso especial, pues el registro resultante tendrá vacía la columna Descripción del informe Lista diaria de CoPilot y sólo se informará del total de carbohidratos en la columna Valor.) La longitud conjunta de todas las cadenas de Descripción no debe superar los 2000 caracteres. La descripción debe dividirse en fragmentos tales que cada cadena no supere los 250 caracteres. Los 250 primeros caracteres se deben almacenar en el campo Descripción0, los 250 caracteres siguientes en el campo Descripción1, y así sucesivamente hasta Descripción7. Examen médico {EVENTTYPE = 6}: El tipo de evento Examen médico permite informar sobre los datos de los exámenes médicos. Campo KEY0 KEY1 KEY2 I0 I1 I2 I3 I4 I5 I6 I7 I8 I9 D0 D1 D2 D3 D4 C0 Datos contenidos ElfHash(Tipo de examen) ElfHash(Examinado por) Notas sobre la implementación Examinado por Texto libre, normalmente el nombre del médico o personal sanitario que ha realizado el examen. DOC14018 Rev. A 03/08 15 Importación de datos TAB y XML C1 C2 C3 C4 C5 C6 C7 C8 C9 Tipo de examen Texto libre que describa el examen. Medicamento {EVENTTYPE = 7}: El tipo de evento Medicamento se utiliza para registrar la administración de cualquier medicamento o tratamiento. Está previsto principalmente para documentar la medicamento oral para la diabetes. No debería utilizarse para describir la administración de insulina, ya que ésta se registra en otros tipos de eventos. Campo KEY0 KEY1 Datos contenidos ElfHash(Dosificación) ElfHash(Nombre de medicamento) ElfHash(Número de comprimidos) Notas sobre la implementación I0 I1 I2 I3 I4 I5 I6 I7 I8 I9 D0 D1 D2 D3 D4 C0 Dosificación C1 Nombre de medicamento C2 Número de comprimidos Texto libre, que normalmente indica la dosis o concentración de cada unidad de medicamento. Texto libre, normalmente el nombre genérico o la marca del medicamento. Texto libre, normalmente el número de unidades de medicamento tomadas en ese momento. KEY2 C3 C4 C5 C6 DOC14018 Rev. A 03/08 16 Importación de datos TAB y XML C7 C8 C9 Notas {EVENTTYPE = 8}: El tipo de evento Notas utiliza el campo COMMENT como campo de datos primario, pero se proporcionan otros dos campos por si son necesarios. Campo Datos contenidos KEY0 ElfHash(Valor diverso) KEY1 ElfHash(Nombre diverso) KEY2 I0 I1 I2 I3 I4 I5 I6 I7 I8 I9 D0 D1 D2 D3 D4 C0 Nombre diverso C1 Valor diverso Notas sobre la implementación Texto libre que se utiliza para clases o tipos de notas o comentarios. (Opcional) Texto libre, normalmente no se utiliza. Puede emplearse para representar la información de algún tipo de “valor” relacionado con la nota. (Opcional) C2 C3 C4 C5 C6 C7 C8 C9 DOC14018 Rev. A 03/08 17 Importación de datos TAB y XML Estado de salud {EVENTTYPE = 9}: El tipo de evento Estado de salud se utiliza para registrar información relacionada con el estado de salud actual. Campo Datos contenidos KEY0 ElfHash(Estado de salud) KEY1 KEY2 I0 I1 I2 I3 I4 I5 I6 I7 I8 I9 D0 D1 D2 D3 D4 C0 Estado de salud Notas sobre la implementación Texto libre, una palabra o una frase que describa el estado de salud actual. C1 C2 C3 C4 C5 C6 C7 C8 C9 Cetona {EVENTTYPE = 10}: El tipo de evento de cetona está indicado para su uso con el resultado de cetona. Campo Datos contenidos KEY0 Trunc(Lectura * 1000) KEY1 KEY2 I0 Marca de control DOC14018 Rev. A 03/08 Notas sobre la implementación 0 = Sin valor de control. 1 = Valor de control. 18 Importación de datos TAB y XML I1 I2 I3 I4 I5 I6 I7 I8 I9 D0 D1 D2 D3 D4 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 Marca de fuera del rango -1 = Bajo (1 negativo). 0 = Dentro del rango. 1 = Alto. Marca de temperatura 0 = Dentro del rango. 1 = Fuera del rango de temperatura. Lectura Valor de cetona, expresado en mmol/L. Sitio de muestra Código de calibración Estado de dispositivo Texto libre. (Opcional) Texto libre. (Opcional) Texto libre. (Opcional) Alarma {EVENTTYPE = 15}: El tipo de evento Alarma se ha creado específicamente para permitir la notificación de alarmas desde el FreeStyle Navigator Continuous Glucose Monitor; sin embargo, puede utilizarse con cualquier alarma que se genere sobre la glucosa. Campo Datos contenidos KEY0 Tipo de alarma KEY1 KEY2 I0 Tipo de alarma I1 Valor de glucosa DOC14018 Rev. A 03/08 Notas sobre la implementación 0 = Hipo. 1 = Hiper. 2 = Hipo inminente. 3 = Hiper inminente. En mg/dL. 19 Importación de datos TAB y XML I2 Inminencia de alarma Expresada en minutos (representa la “sensibilidad” de la alarma e indica la antelación con que se avisa al usuario de un evento de alarma inminente). Nota: Este dato no se tiene en cuenta a menos que Tipo de alarma = 2 ó 3. I3 I4 I5 I6 I7 I8 I9 D0 D1 D2 D3 D4 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 Eventos genéricos {EVENTTYPE = 16}: El tipo Eventos genéricos se ha creado específicamente para dar cabida a eventos genéricos producidos por el FreeStyle Navigator Continuous Glucose Monitor; sin embargo, puede utilizarse con eventos genéricos que podrían clasificarse con un número entero. Nota: FreeStyle Navigator utiliza eventos genéricos de los tipos del 0 al 7. Campo Datos contenidos KEY0 Tipo genérico KEY1 KEY2 I0 Tipo genérico I1 I2 I3 I4 I5 DOC14018 Rev. A 03/08 Notas sobre la implementación Cualquier número entero válido. 20 Importación de datos TAB y XML I6 I7 I8 I9 D0 D1 D2 D3 D4 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 Normas XML El formato de importación de XML de CoPilot sigue las convenciones de la versión 1.0 de XML; sin embargo, no se garantiza una compatibilidad total con la norma XML. Para lograr una implementación satisfactoria de la importación de XML, utilice los siguientes formatos de ejemplo, en la forma exacta en que se describen. Campos de datos En general, con el formato XML se importan los mismos campos y registros de datos que se han descrito para la importación de archivos TAB. En la importación de XML son de aplicación las siguientes reglas: •Todas las entradas de datos deben tener comillas al principio y al final. •Los campos de tipo texto de cadena (campos “C”) que estén vacíos deben introducirse explícitamente con un par de comillas (“”). •Los campos numéricos (campos “I” y “D”) que no se utilicen deben introducirse con un cero (“0”). DOC14018 Rev. A 03/08 21 Importación de datos TAB y XML Estructura del formato A continuación se presenta un ejemplo de un archivo codificado en XML. Este archivo contiene dos registros: para los fines del ejemplo, el primero de ellos contiene un evento de comida, mientras que el segundo contiene un evento de glucosa. <?xml version=”1.0” encoding=”windows-1252” standalone=”yes> <RECORDS> <RECORD> <ROW DATEEVENT=”38767.5347222222” TIMESLOT=”1” EVENTTYPE=”5” DEVICE_MODEL=”Navigator” DEVICE_ID=”BAAF300-80356U” VENDOR_EVENT_TYPE_ID=”0” VENDOR_EVENT_ID=”1073741901-12” KEY0=”10000” KEY1=”3289648” KEY2=”0” I0=”0” I1=”0” I2=”0” I3=”0” I4=”0” I5=”0” I6=”0” I7=”0” I8=”0” I9=”0” D0=”0” D1=”10” D2=”0” D3=”0” D4=”0” C0=”” C1=”” C2=”” C3=”” DOC14018 Rev. A 03/08 22 Importación de datos TAB y XML C4=”” C5=”” C6=”” C7=”” C8=”Lunch” C9=”” ISMANUAL=”1” COMMENT=”” DELETED=”0” /> </RECORD> <RECORD> <ROW DATEEVENT=”38767.00625” TIMESLOT=”7” EVENTTYPE=”1” DEVICE_MODEL=”Navigator” DEVICE_ID=”BAAF300-80356U” VENDOR_EVENT_TYPE_ID=”0” VENDOR_EVENT_ID=”7508-12” KEY0=”145” KEY1=”0” KEY2=”0” I0=”0” I1=”145” I2=”0” I3=”0” I4=”0” I5=”1” I6=”3” I7=”0” I8=”0” I9=”0” D0=”0” D1=”0” D2=”0” D3=”0” DOC14018 Rev. A 03/08 23 Importación de datos TAB y XML D4=”0” C0=”” C1=”” C2=”1” C3=”” C4=”” C5=”” C6=”” C7=”” C8=”” C9=”” ISMANUAL=”0” COMMENT=”” DELETED=”0” /> </RECORD> </RECORDS> ElfHash En esta sección se describe la implementación de la codificación del algoritmo ElfHash, que se utiliza para generar números enteros de resumen a partir de cadenas de caracteres en los campos KEY0, KEY1 y KEY2. Esta implementación está en Pascal. function ElfHash( const Value : string ) : Integer; var i, x : Integer; begin Result := 0; for i := 1 to Length( Value ) do begin Result := ( Result shl 4 ) + Ord( Value[ i ] ); x := Result and $F0000000; if ( x <> 0 ) then Result := Result xor ( x shr 24 ); Result := Result and ( not x ); end; end; DOC14018 Rev. A 03/08 24