Importación de datos TAB y XML

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