ES2638667T3

ES2638667T3 - Pruebas estructuradas definidas por el usuario para su uso en el cuidado de la diabetes

Info

Publication number: ES2638667T3
Application number: ES12722326.1T
Authority: ES
Inventors: Steven A. BOUSAMRA
Original assignee: F Hoffmann La Roche AG
Current assignee: F Hoffmann La Roche AG
Priority date: 2011-05-13
Filing date: 2012-05-11
Publication date: 2017-10-23
Anticipated expiration: 2032-05-11
Also published as: EP2706914B1; WO2012156326A3; US10448869B2; US20200000385A1; US20120289802A1; CN103533889A; WO2012156326A2; EP2706914A2; US11864888B2; CN103533889B

Abstract

Un método para medir los niveles de glucosa de un paciente, que comprende: - recibir (54) del paciente un objetivo para una prueba estructurada; - identificar (55) una plantilla de prueba que corresponde al objetivo a partir de una pluralidad de plantillas de prueba predefinidas, en la que la plantilla de prueba está compuesta por múltiples instancias de muestra durante un período de tiempo, siendo las instancias múltiples de muestreo una medición de glucosa o un par de mediciones de glucosa en sangre antes y después de un evento, y las múltiples instancias de muestra que proporcionan un grupo de muestras; - presentar (56) al paciente con una pluralidad de criterios contextuales para la plantilla de prueba identificada; - recibir (57) la selección de uno o más criterios contextuales asociados con el evento por el paciente de la pluralidad de criterios contextuales; - construir (58) una prueba estructurada que incluya el criterio contextual seleccionado por el paciente y de acuerdo con la plantilla de prueba identificada; y - administrar la prueba estructurada al paciente, incluyendo - sugerir al paciente proporcionar una muestra de sangre a un medidor de glucosa; - recolectar los datos que incluyan datos de medición de glucosa en sangre; - presentar una pregunta al paciente para cada criterio contextual; - recibir respuestas a las preguntas de parte del paciente; y - asociar las respuestas con los datos recolectados durante la prueba estructurada; de manera que las etapas del método son implementadas por un procesador de ordenador de un dispositivo; Caracterizada porque - la pluralidad de criterios contextuales presentados al usuario que son un subconjunto de criterios contextuales que son filtrados o preseleccionados por el procesador del ordenador a partir de un grupo grande de criterios contextuales teniendo en cuenta el objetivo para la prueba estructurada; - determinar una variabilidad del grupo de muestras; y - cuando, mientras que la prueba estructurada se administra al usuario, la variabilidad es inferior a un umbral predeterminado que permite una modificación de los criterios contextuales y cuando, mientras la prueba estructurada se administra al usuario, la variabilidad es mayor que el umbral predeterminado no permitiendo una modificación de los criterios contextuales.

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

DESCRIPCION

Pruebas estructuradas definidas por el usuario para su uso en el cuidado de la diabetes CAMPO

La presente divulgacion se refiere a metodos de prueba estructurados para el diagnostico y la terapia de apoyo de pacientes con enfermedades cronicas, tales como diabetes.

ANTECEDENTES

Para las personas con diabetes, el control exitoso requiere monitorizar los efectos que los cambios en el estilo de vida pueden tener en los marcos de tiempo a corto y largo plazo. Las pruebas regulares de su nivel de glucosa en sangre pueden ser una parte importante del control de la diabetes como una forma de rastrear los cambios a lo largo del dfa. Por ejemplo, a menudo se utilizan dispositivos de mano portatiles de diagnostico medico para medir concentraciones de componentes biologicamente significativos de fluidos corporales, tales como, por ejemplo, la concentracion de glucosa en la sangre. Para probar la glucosa con un medidor de glucosa, se puede colocar una pequena muestra de sangre en una tira de prueba desechable. El medidor de mano portatil de glucosa puede incluir un puerto de tira que recibe la tira de prueba desechable. La tira de prueba puede recubrirse con productos qmmicos (glucosa oxidasa, deshidrogenasa o hexoquinasa) que se combinan con glucosa en sangre permitiendo medir la concentracion de glucosa en la muestra de sangre. El medidor de mano portatil de glucosa muestra entonces la concentracion de glucosa como un numero (o valor de medicion de glucosa). Como resultado, los dispositivos de mano portatiles de diagnostico medico y sus accesorios pueden trabajar juntos para medir la cantidad de glucosa en la sangre y ser usados para monitorizar los niveles de glucosa en el hogar, establecimiento de salud u otro lugar, por ejemplo, por personas con diabetes o por un profesional de atencion sanitaria.

Los pacientes y los profesionales atencion sanitaria pueden por lo tanto rastrear y analizar las mediciones de glucosa durante un penodo de tiempo para evaluar los cambios en el paciente durante el transcurso de un dfa, semana u otro plazo deseable. Por ejemplo, algunos profesionales de atencion sanitaria pueden instruir a un paciente a obtener mediciones de glucosa siete o mas veces al dfa en un curso de unos pocos dfas consecutivos para que los pacientes pueden observar los cambios que realizan sus mediciones. Sin embargo, la importancia en el cambio de los factores del estilo de vida, tales como porciones de comida o actividad ffsica) puede no ser entendida por los pacientes.

El documento de los Estados Unidos US 2010/0218132 A1 divulga un sistema y un metodo para la recopilacion de datos y el analisis de datos de un procedimiento de recopilacion estructurado. Se puede construir un procedimiento estructurado de recopilacion para una pregunta de uso medico seleccionada. Durante la ejecucion del procedimiento de recopilacion estructurada pueden tenerse en cuenta criterios de adherencia.

Por lo tanto, puede ser deseable proporcionar metodos y dispositivos que permitan a los pacientes comprender mejor que factores pueden afectar las mediciones de glucosa. Esta seccion proporciona informacion de antecedentes relacionada con la presente divulgacion que no es necesariamente de la tecnica anterior.

RESUMEN

La invencion es un metodo de acuerdo con la reivindicacion 1 y un dispositivo controlador para diabetes de acuerdo con la reivindicacion 4 para medir los niveles de glucosa que permite a los pacientes comprender mejor que factores pueden afectar la medida de glucosa en sangre.

En otro aspecto de la divulgacion, se proporciona un metodo para construir una prueba estructurada que tiene criterios de adherencia definidos por el usuario. El metodo incluye: presentar a un paciente con una pluralidad de criterios contextuales para una prueba estructurada; recibir una seleccion de uno o mas criterios contextuales a partir de la pluralidad de criterios contextuales; y la construccion de una prueba estructurada que incluya el criterio contextual seleccionado por el paciente. Durante la administracion de la prueba estructurada, se evalua cada uno de los criterios contextuales seleccionados por el paciente. Los datos de muestra adquiridos durante la prueba estructurada se reportan como a conformidad cuando cada uno de los criterios de contexto seleccionados por el paciente se cumplio durante la administracion de la prueba estructurada o marcados como no cumplidos cuando al menos un criterio contextual no se cumplio durante la administracion de la prueba estructurada.

En otro aspecto mas de la divulgacion, el metodo para construir una prueba estructurada se extiende para hacer pruebas de tipo pruebas en parejas. El metodo incluye: sugerir al paciente que introduzca una muestra de sangre en un medidor de glucosa antes y despues de un evento dado dentro de una ventana de tiempo que encapsule el evento dado; determinar una medida de glucosa en sangre desde la muestra de entrada de sangre al medidor de glucosa; presentar una pregunta al paciente para datos contextuales sobre otro evento que ocurre fuera de la ventana de tiempo; recibir una respuesta del paciente a la pregunta; y asociar la respuesta con la medida de glucosa en sangre.

5

10

15

20

25

30

35

40

45

50

55

60

65

El metodo puede comprender presentar al paciente con una pluralidad de objetivos para llevar a cabo una prueba estructurada, de manera que cada uno de los objetivos se correlacione con uno de una pluralidad de plantillas de prueba. El metodo puede comprender presentar al paciente con un conjunto de criterios contextuales para la plantilla de prueba seleccionada de manera que un criterio contextual asociado con una plantilla de prueba dada difiera de un criterio contextual asociado con otra plantilla de prueba entre la pluralidad de plantillas de prueba predefinidas. La administracion de la prueba estructurada puede adicionalmente comprender presentar una pregunta al paciente para cada criterio contextual, recibir respuestas a las preguntas de parte del paciente y asociar las respuestas con los datos recogidos durante la prueba estructurada. La administracion de la prueba estructurada al paciente puede comprender ademas sugerir al paciente que introduzca una muestra de sangre en un medidor de glucosa antes y despues de un evento dado dentro de una ventana de tiempo que encapsule el evento dado y presentar una pregunta al paciente para datos contextuales referentes a otro evento que difiere del evento dado. El metodo puede comprender presentar una pregunta al paciente para datos contextuales referentes a otro evento que ocurre fuera de la ventana de tiempo. El metodo puede comprender sugerir al paciente que introduzca una muestra de sangre en el medidor de glucosa en un momento que se produce fuera de la ventana de tiempo. El metodo puede comprender definir un criterio de adherencia para la prueba estructurada y reportar datos recogidos durante la prueba estructurada cuando se cumple el criterio de adherencia para la prueba estructurada. El metodo puede comprender definir el criterio de adherencia con base en el criterio contextual seleccionado.

El metodo puede comprender reportar los datos de muestra adquiridos durante la prueba estructurada como a conformidad cuando el criterio de contexto dado seleccionado por el paciente se cumplio durante la administracion de la prueba estructurada.

El metodo puede comprender presentar al paciente con una pluralidad de criterios contextuales relacionados con una prueba estructurada que se administra al paciente; recibir una seleccion de uno o mas criterios contextuales por el paciente de la pluralidad de criterios contextuales; y presentar las preguntas al paciente para cada uno de los criterios contextuales. El metodo puede comprender ademas construir una prueba estructurada que incluya el criterio contextual seleccionado por el paciente, administrar la prueba estructurada al paciente, evaluar si un criterio contextual determinado seleccionado por el paciente se ha cumplido durante la administracion de la prueba estructurada y marcar los datos de muestra adquiridos durante la prueba estructurada como no conformes cuando el criterio contextual dado no se cumplio durante la administracion de la prueba estructurada.

El metodo puede comprender analizar instancias de muestra adquiridas a lo largo de la serie de las pruebas estructuradas y presentar los resultados del analisis al paciente. El metodo puede comprender sugerir al paciente que clasifique la instancia de muestra para una prueba de estructura dada e ignorar la instancia de muestra para la prueba estructurada dada de analisis posterior cuando la instancia de muestra es categorizada por el paciente como atfpica. El metodo puede comprender presentar una pregunta al paciente durante al menos un criterio contextual durante la administracion de una prueba estructurada dada, recibir una respuesta a la pregunta de parte del paciente, sugerir al paciente a categorizar la instancia de muestra para la prueba de estructura dada y sin tener en cuenta la instancia de la muestra para la prueba estructurada dada del analisis subsiguiente cuando la instancia de muestra se categoriza como atfpica por el paciente. El metodo puede comprender ademas guiar al paciente a traves de una primera serie de pruebas estructuradas construidas usando los criterios contextuales seleccionados por el paciente; derivar una medicion estandar de glucosa en sangre de las instancias de muestra adquiridas durante la primera serie de pruebas estructuradas, sugiriendo al paciente a cambiar una variable asociada con la primera serie de pruebas estructuradas, guiando al paciente a traves de una segunda serie de pruebas estructuradas, donde la segunda serie de pruebas estructuradas tienen un valor para la variable diferente de la primera serie de pruebas estructuradas pero por lo demas construidas utilizando los criterios contextuales seleccionados por el paciente y derivando una medida cambiada de glucosa en sangre de los casos de muestra adquiridos durante la segunda serie de pruebas estructuradas. El metodo puede comprender presentar los resultados de la primera y segunda series de pruebas estructuradas al paciente, incluyendo una comparacion de la medida estandar de glucosa en sangre y la medida de glucosa en sangre cambiada. El metodo puede comprender analizar ejemplos de muestras adquiridos durante la primera y segunda series de pruebas estructuradas y presentar los resultados del analisis al paciente.

El dispositivo controlador para diabetes puede comprender un modulo de medicion de glucosa en sangre que mide selectivamente la glucosa en sangre en una muestra de sangre. El modulo de configuracion de prueba puede presentar al usuario una pluralidad de objetivos para realizar una prueba estructurada, de manera que cada uno de los objetivos se correlacione con una de la pluralidad de plantillas de prueba predefinidas. El modulo de configuracion de prueba puede presentar al usuario un conjunto de criterios contextuales para la plantilla de prueba seleccionada de modo que un criterio contextual asociado con una plantilla de prueba dada difiera de un criterio contextual asociado con otra plantilla de prueba entre la pluralidad de plantillas de prueba predefinidas. El modulo de administracion de prueba puede presentar una pregunta al usuario para cada criterio contextual, puede recibir respuestas de las preguntas del usuario y puede asociar las respuestas con los datos recogidos durante la prueba estructurada. El modulo de administrador de prueba puede evaluar si un criterio contextual determinado seleccionado por el paciente se ha cumplido durante la administracion de la prueba estructurada y puede reportar los datos de muestra adquiridos durante la prueba estructurada como a conformidad cuando el criterio contextual dado seleccionado por el paciente se cumplio durante la administracion de la prueba estructurada. El modulo de

5

10

15

20

25

30

35

40

45

50

55

60

65

administrador de prueba puede etiquetar datos de muestra adquiridos durante la prueba estructurada como no conformes cuando el criterio contextual dado no se cumplio durante la administracion de la prueba estructurada.

Esta seccion proporciona un resumen general de la divulgacion y no es una descripcion completa de su alcance completo ni de todas sus caractensticas. Otras areas de aplicabilidad resultaran evidentes a partir de la descripcion proporcionada aqrn. La descripcion y los ejemplos espedficos en este resumen estan destinados unicamente a fines ilustrativos y no pretenden limitar el alcance de la presente divulgacion.

BREVE DESCRIPCION DE LOS DIBUJOS

Figura 1 es un dibujo que representa un paciente y un medico clmico de tratamiento;

Figura 2 es un dibujo que ilustra un paciente con un monitor de glucosa continuo (CGM), una bomba de infusion de insulina duradera ambulatoria, una bomba de infusion de insulina no duradera ambulatoria y un controlador para diabetes;

Figura 3 es un diagrama que muestra un sistema controlador para diabetes de ejemplo utilizado por pacientes y medicos clmicos para controlar la diabetes;

Figura 4 es un diagrama de bloques funcional de un controlador para diabetes de ejemplo;

Figuras 5A, 5B son diagramas de flujo que ilustran metodos de ejemplo mediante los cuales los pacientes pueden construir pruebas estructuradas;

Figura 6 es un diagrama de flujo que representa un metodo para implementar un ensayo estructurado; y

Figura 7 es un diagrama que ilustra casos de uso de ejemplo para los resultados de pruebas de informe.

Los dibujos descritos aqrn son para propositos ilustrativos solamente de realizaciones seleccionadas y no todas las implementaciones posibles, y no pretenden limitar el alcance de la presente divulgacion. Los numeros de referencia correspondientes indican las partes correspondientes a lo largo de las diversas vistas de los dibujos.

DESCRIPCION DETALLADA

Haciendo referencia a la figura 1, una persona 100 con diabetes y un profesional 102 de atencion sanitaria se muestran en un entorno clmico. Las personas con diabetes incluyen personas con smdrome metabolico, prediabetes, diabeticos tipo 1, diabeticos tipo 2 y diabeticos gestacionales y se denominan colectivamente como un paciente. Los proveedores de atencion sanitaria para la diabetes son diversos e incluyen enfermeras, profesionales de enfermena, medicos y endocrinologos y se denominan colectivamente como personal clmico. Aunque esta divulgacion hace referencia al cuidado de la diabetes, se entiende facilmente que los conceptos relacionados con la prueba estructurada divugada aqrn pueden aplicarse a otros tipos de enfermedades cronicas. Del mismo modo, esta divulgcion hace referencia a medidas de glucosa en sangre, pero los conceptos son extensibles a otros tipos de biomarcadores de un paciente, incluyendo pero sin limitarse a un valor de glucosa intersticial, un valor de HbA1c, una medicion de la frecuencia cardiaca, una medicion de la presion sangumea, lfpidos, trigliceridos, colesterol y similares.

Durante una consulta de atencion sanitaria, el paciente 100 comparte tfpicamente con el medico 102 clmico una variedad de datos del paciente que incluyen mediciones de glucosa en sangre, datos continuos del monitor de glucosa, cantidades de insulina infundida, cantidades de alimentos y bebidas consumidas, horarios de ejercicio y otra informacion de estilo de vida. El medico 102 clmico puede obtener datos adicionales del paciente que incluyen mediciones de HbA1C, niveles de colesterol, trigliceridos, presion sangumea y peso del paciente 100. Los datos del paciente se pueden grabar manualmente o electronicamente en un dispositivo 104 portatil controlador para diabetes, un software de analisis para diabetes ejecutado en un ordenador personal (PC) 106, y/o un sitio en la red de analisis para diabetes (no mostrado). El medico 102 clmico puede analizar los datos del paciente de forma manual o electronica usando el software de analisis para diabetes y/o el sitio en la red de analisis para diabetes. Despues de analizar los datos del paciente y revisar la adherencia del paciente 100 a la terapia previamente prescrita, el medico 102 clmico puede decidir si modifica la terapia para el paciente 100.

Haciendo referencia a la figura 2, el paciente 100 puede utilizar un monitor 200 de glucosa continuo (CGM), una bomba 202 de infusion de insulina no duradera ambulatoria o una bomba 204 de infusion de insulina duradera ambulatoria (de aqrn en adelante bomba 202 o 204 de insulina) y el dispositivo 104 portatil controlador para diabetes (de aqrn en adelante controlador 104 para diabetes). El CGM 200 utiliza un sensor subcutaneo para detectar y monitorizar la cantidad de glucosa en la sangre del paciente 100 y comunica lecturas correspondientes al controlador para diabetes 104.

5

10

15

20

25

30

35

40

45

50

55

60

65

El controlador 104 para diabetes realiza varias tareas que incluyen medir y registrar los niveles de glucosa en sangre, determinar una cantidad de insulina que se administra al paciente 100 a traves de la bomba 202 o 204 de insulina, recibir datos del paciente a traves de una interfaz de usuario, archivar los datos del paciente, etc. El controlador 104 para diabetes recibe periodicamente lecturas del CGM 200 que indica el nivel de insulina en la sangre del paciente 100. El controlador 104 para diabetes transmite instrucciones a la bomba 202 o 204 de insulina, que suministra insulina al paciente 100. La insulina puede administrate de forma programada en forma de una dosis basal, que mantiene un nivel de insulina predeterminado en la sangre del paciente 100. Ademas, la insulina puede administrarse en forma de una dosis en bolo, lo que eleva la cantidad de insulina en la sangre del paciente 100 por una cantidad predeterminada.

Haciendo referencia a la figura 3, un sistema 300 controlador para diabetes utilizado por el paciente 100 y el medico 102 clmico incluye uno o mas de los siguientes dispositivos: el controlador 104 para diabetes, el monitor 200 de glucosa continuo (CGM), la bomba 202 o 204 de insulina, un dispositivo 302 movil, el PC 106 con el software de analisis para diabetes y otros dispositivos 304 de atencion sanitaria. El controlador 104 para diabetes esta configurado como un nucleo de sistema y se comunica con los dispositivos del sistema 300 controlador para diabetes. Alternativamente, la bomba 204 de insulina o el dispositivo 302 movil pueden servir como el nucleo del sistema. La comunicacion entre los dispositivos del sistema 300 controlador para diabetes puede realizarse utilizando interfaces inalambricas (por ejemplo, Bluetooth) y/o interfaces de cable (por ejemplo, USB). Los protocolos de comunicacion utilizados por estos dispositivos pueden incluir protocolos que cumplan con la norma IEEE 11073, como se extiende usando las normas proporcionadas por las Normas de Diseno de Continua® Health Alliance. Ademas, los sistemas de registros medicos como Microsoft® HealthVault™ y Google™ Health pueden ser utilizados por el paciente 100 y el medico 102 clmico para intercambiar informacion.

El controlador 104 para diabetes puede recibir resultados de glucosa en sangre de una o mas fuentes (por ejemplo, del CGM 200). El CGM 200 mide continuamente el nivel de glucosa en sangre del paciente 100. El cGm 200 comunica periodicamente el nivel de glucosa en sangre al controlador 104 para diabetes. El controlador 104 para diabetes y el CGM 200 se comunican de forma inalambrica, por ejemplo, usando un protocolo propietario Gazell inalambrico desarrollado por Nordic Semiconductor, Inc.

Adicionalmente, el controlador 104 para diabetes incluye un medidor de glucosa en sangre (BGM) y un puerto que comunica con el BGM (no mostrado). El puerto puede recibir una tira 306 de medicion de glucosa en sangre. El paciente 100 deposita una muestra de sangre u otro fluido corporal en la tira 306 de medicion de glucosa en sangre. El BGM analiza la muestra y mide el nivel de glucosa en sangre en la muestra. El nivel de glucosa en sangre medido a partir de la muestra y/o el nivel de glucosa en sangre lefdo por el CGM 200 puede usarse para determinar la cantidad de insulina a administrar al paciente 100. Para crear evidencia objetiva repetible que puede usarse para hacer un examen medico u optimizacion, el controlador 104 para diabetes puede ejecutar una o mas pruebas estructuradas o procedimientos de recoleccion como se describe con mas detalle a continuacion.

El controlador 104 de diabetes se comunica con la bomba 202 o 204 de insulina. La bomba 202 o 204 de insulina puede configurarse para recibir instrucciones del controlador 104 para diabetes para suministrar una cantidad predeterminada de insulina al paciente 100. Adicionalmente, la bomba 202 o 204 de insulina puede recibir otra informacion incluyendo horarios de comidas y/u horarios de ejercicios del paciente 100. La bomba 202 o 204 de insulina puede recomendar una cantidad de insulina para administrar con base en la informacion adicional.

La bomba 202 o 204 de insulina tambien puede comunicar datos al controlador 104 de diabetes. Los datos pueden incluir cantidades de insulina suministradas al paciente 100, tiempos correspondientes de suministro y estado de la bomba. El controlador 104 para diabetes y la bomba 202 o 204 de insulina pueden comunicarse utilizando un protocolo de comunicacion inalambrica tal como Bluetooth. Tambien se pueden usar otros protocolos de comunicacion inalambrica o cableada.

Ademas, el controlador 104 para diabetes puede comunicarse con los otros dispositivos 304 de atencion sanitaria. Por ejemplo, los otros dispositivos 304 de atencion sanitaria pueden incluir un medidor de presion sangumea, una escala de peso, un podometro, un oxfmetro de pulso de punta de dedo, un termometro, etc. Los dispositivos 304 de atencion sanitaria obtienen y comunican informacion de salud personal del paciente 100 al controlador 104 para diabetes a traves de interfaces inalambricas, USB u otras. Los otros dispositivos 304 de atencion sanitaria pueden utilizar protocolos de comunicacion que cumplan con ISO/IEEE 11073. El controlador 104 para diabetes puede comunicarse con los otros dispositivos 304 de atencion sanitaria utilizando interfaces incluyendo Bluetooth, USB, etc. Ademas, los dispositivos del sistema 300 controlador para diabetes pueden comunicarse entre sf a traves del controlador 104 para diabetes.

El controlador 104 para diabetes puede comunicarse con la PC 106 utilizando Bluetooth, USB u otras interfaces. Un software controlador para diabetes que se ejecuta en la PC 106 incluye un analizador-configurador que almacena la informacion de configuracion de los dispositivos del sistema 300 controlador para diabetes. El configuradortiene una base de datos para almacenar informacion de configuracion del controlador 104 para diabetes y los otros dispositivos. El configurador puede comunicarse con los usuarios a traves de pantallas de la red o de ordenador estandar en aplicaciones sin red. El configurador transmite configuraciones aprobadas por el usuario a los

5

10

15

20

25

30

35

40

45

50

55

60

65

dispositivos del sistema 300 controlador para diabetes. El analizador recupera datos del controlador 104 para diabetes, almacena los datos en una base de datos y emite resultados de analisis a traves de paginas estandar de la red o pantallas de ordenador en aplicaciones sin base en la red. El Sistema Controlador de la Diabetes Accu-Chek 360® es un ejemplo de un producto de software controlador para diabetes comercialmente disponible, aunque otros productos tambien entran dentro del alcance de esta divulgacion.

El controlador 104 para diabetes puede comunicarse con el dispositivo 302 movil utilizando Bluetooth. El dispositivo movil 302 puede incluir un telefono celular, un buscapersonas o un asistente digital personal (PDA). El controlador 104 para diabetes puede enviar mensajes a una red externa a traves del dispositivo 302 movil. El dispositivo 302 movil puede transmitir mensajes a la red externa al recibir solicitudes del controlador 104 para diabetes.

Un controlador 104 para diabetes de ejemplo se describe adicionalmente en relacion con la figura 4. El controlador 104 para diabetes comprende un modulo 400 medidor de glucosa en sangre (BGM), un modulo 402 de comunicacion, un modulo 404 de interfaz de usuario, interfases 406 de usuario, un modulo 408 de procesamiento, memoria 410 y un modulo 412 de energfa. El modulo 404 de interfaz de usuario y el modulo 408 de procesamiento pueden implementarse mediante un modulo 409 de procesamiento de aplicaciones. El modulo 400 BGM incluye un motor de medicion de glucosa en sangre que analiza muestras proporcionadas por el paciente 100 en la tira 306 de medicion de glucosa en sangre y que mide la cantidad de glucosa en sangre en las muestras. El modulo 402 de comunicacion incluye multiples radios que se comunican con diferentes dispositivos del sistema 300 controlador para diabetes. El modulo 404 de interfaz de usuario hace referencia al controlador 104 para diabetes a varias interfases 406 de usuario que el paciente 100 puede utilizar para interactuar con el controlador 104 para diabetes. Por ejemplo, las interfases 406 de usuario pueden incluir teclas, conmutadores, una pantalla, un altavoz, un microfono, un puerto de tarjeta digital segura (SD), un puerto USB, etc. (no mostrado).

El modulo 408 de procesamiento procesa los datos recibidos desde el modulo 400 BGM, el modulo 402 de comunicacion y el modulo 404 de interfaz de usuario. El modulo 408 de procesamiento utiliza memoria 410 para procesar y almacenar datos. La memoria 410 puede incluir memoria volatil y no volatil. El modulo 408 de procesamiento envfa datos y recibe datos desde las interfases 406 de usuario a traves del modulo 404 de interfaz de usuario. El modulo 408 de procesamiento envfa datos a y recibe datos de los dispositivos del sistema 300 controlador para diabetes a traves del modulo 402 de comunicacion. El modulo 412 de energfa suministra energfa a los componentes del controlador 104 para diabetes. El modulo 412 de energfa incluye una batena recargable. La batena se puede recargar con un adaptador que se conecta a una toma de corriente. La batena tambien se puede cargar a traves del puerto USB del controlador 104 para diabetes.

Para los fines de esta divulgacion, el controlador 104 para diabetes sirve como un dispositivo de recoleccion. Sin embargo, el dispositivo de recoleccion puede ser cualquier dispositivo electronico portatil que pueda proporcionar un mecanismo de adquisicion para determinar y almacenar medidas fisiologicas de una persona. Por ejemplo, los medidores de glucosa en sangre autocontrolados y los dispositivos continuos de monitoreo de glucosa son ejemplos de dispositivos de recoleccion usados para medir la glucosa en sangre en el cuidado de la diabetes. En estos ejemplos, el controlador para diabetes (que puede residir, por ejemplo, en un telefono portatil) trabaja cooperativamente con un dispositivo recolector ffsicamente separado para administrar una prueba estructurada y registrar datos asociados con la prueba administrada. Es decir, el controlador para diabetes puede sugerirle a una persona que introduzca una muestra de sangre en un medidor de glucosa o interactuar con la persona de acuerdo con la prueba estructurada; mientras que el medidor de glucosa analiza muestras de sangre y almacena medidas de glucosa de las muestras de sangre. Las medidas de glucosa pueden ser posteriormente transmitidas al controlador para diabetes para su procesamiento posterior.

Las Figuras 5A y 5B representan metodos de ejemplo mediante los cuales los pacientes son capaces de construir una prueba estructurada que permite a los pacientes comprender mejor los factores que pueden afectar las mediciones de glucosa en sangre. En una realizacion de ejemplo, los metodos para construir y administrar pruebas estructuradas se implementan en un software ejecutado por un procesador del controlador 104 para diabetes. Se preve que un paciente (o medico) podna construir una prueba estructurada en otro dispositivo (por ejemplo, una PC de escritorio) y posteriormente descargada para su ejecucion por el controlador 104 para diabetes.

Con referencia a la figura 5A, un paciente puede comenzar seleccionando un tipo particular de medida de glucosa en sangre que sea de interes para el paciente. Por ejemplo, el paciente puede estar interesado en que factores afectan una medida de glucosa en sangre en ayunas, una medida de glucosa preprandial o una medida de glucosa postprandial. En otro ejemplo, los pacientes pueden estar interesados en los factores que afectan a una serie de pruebas de glucosa emparejadas para ayudar a entender problemas particulares con el comportamiento o la terapia. Cada prueba de glucosa emparejada implica la obtencion de pares de medidas bG antes y despues de eventos particulares. Por ejemplo, un individuo puede obtener un valor bG antes de una comida espedfica, por ejemplo antes del almuerzo, y otro valor bG dentro de un tiempo especificado despues del almuerzo. Los valores "antes" y "despues" de bG forman un "par" relacionado de valores de bG y comunmente se denomina prueba de "Pruebas en Pares" (TIPs). Otros tipos de mediciones se contemplan tambien en esta divulgacion.

5

10

15

20

25

30

35

40

45

50

55

60

En una realizacion de ejemplo, una pluralidad de tipos de medicion diferentes se almacena en el controlador para diabetes y se presentan en 51 en una pantalla para su seleccion por el paciente. El paciente a su vez selecciona un tipo particular de medicion que es capturado en 52 por el controlador para diabetes. Por ejemplo, el paciente puede seleccionar una medida de ayuno matutino. Para este tipo de medicion, el paciente se abstiene de comer o beber durante un penodo de tiempo antes de obtener una medida de glucosa en sangre. El paciente, sin embargo, puede no entender que factores afectan la medida. Por lo tanto, se le presenta al paciente en 56 con una plantilla de prueba propuesta para este tipo particular de medicion.

Cada tipo de medicion se correlaciona con una plantilla de prueba propuesta. En funcionamiento, el controlador para diabetes recupera la plantilla de prueba propuesta que corresponde a la seleccion de medicion. La plantilla de prueba propuesta esta compuesta por una serie de eventos a realizar por el paciente, incluyendo una sugerencia para que el paciente proporcione una muestra de sangre a un medidor de glucosa. La plantilla de prueba propuesta incluira ademas criterios contextuales que pueden afectar la medicion. La plantilla de prueba propuesta para una medida de ayuno matutino puede incluir los siguientes eventos:

Plantilla de prueba para ayuno matutino:

Sugerir al paciente que tome una medida de bG de referencia antes de tomar el aperitivo

Sugerir al paciente dar informacion sobre el aperitivo

Sugerir al paciente que tome la insulina de la noche

Confirmar la cantidad de insulina tomada por el paciente

Sugerir al paciente dar informacion sobre ejercicio

Sugerir al paciente dar la cantidad de horas dormidas

Confirmar el ayuno por el paciente

Sugerir al paciente que tome la medida de bG de la manana

Al presentar al paciente con una lista de eventos, el paciente comienza a aprender que factores pueden afectar a una medida en particular. Para construir una prueba estructurada, el paciente puede seleccionar que eventos son aplicables al paciente. En una realizacion simplificada, los eventos seleccionados se correlacionan directamente con los criterios contextuales usados para construir la prueba. Algunos de los eventos pueden ser necesarios para cada instancia de muestra (por ejemplo, confirmar la cantidad de insulina tomada o confirmar el ayuno); mientras que otros eventos pueden ser opcionales (por ejemplo, informacion sobre un aperitivo nocturno o ejercicio).

Ademas, se presenta al paciente con una lista de criterios contextuales priorizada. Al construir una prueba estructurada, el paciente puede seleccionar cual de los criterios contextuales (o entradas contextuales) son aplicables al paciente. Por ejemplo, un paciente que normalmente disfruta de un aperitivo nocturno puede optar por investigar el efecto de su aperitivo nocturno en el valor de ayuno matutino. El sistema presentana entonces al usuario una lista priorizada de criterios contextuales incluyendo la cantidad de su administracion de insulina, si consumio alcohol, el tamano de su aperitivo, y similares. El usuario puede seleccionar los criterios contextuales de la lista que desea evaluar y anular la seleccion de los que no desea. Colectivamente o individualmente, el criterio contextual puede considerarse como una "variable bajo prueba". En otros casos, el paciente puede seleccionar criterios contextuales relacionados con el ejercicio (como la duracion del ejercicio) pero no de los aperitivos, o seleccionar criterios contextuales relacionados tanto con el aperitivo como con el ejercicio. Los criterios contextuales seleccionados por el paciente son capturados por el controlador para diabetes en 57 y luego utilizados para construir en 58 una prueba estructurada para el paciente de la manera descrita mas adelante. Se entiende facilmente que diferentes tipos de mediciones se correlacionanan con diferentes plantillas de prueba y diferentes plantillas de prueba estanan compuestas de diferentes eventos y/o criterios contextuales. En otras palabras, la seleccion de criterios contextuales presentados al usuario puede ser un subconjunto de criterios contextuales que son filtrados o preseleccionados a partir de una gran agrupacion de criterios con base en el tipo de medicion.

En otro ejemplo, el paciente puede seleccionar una prueba TIPs para un evento dado, tal como un regimen de ejercicio matutino. Para este tipo de medicion, se pide al paciente que tome una medida de glucosa en sangre antes y despues del evento dado. Dependiendo del tipo de evento seleccionado, se presenta al paciente una plantilla de prueba propuesta para el tipo de evento seleccionado. Para una prueba TIPs asociada con un regimen de ejercicio matutino, la plantilla de prueba propuesta puede incluir los siguientes eventos:

5

10

15

20

25

30

35

40

45

50

55

60

Plantilla de prueba para el regimen de ejercicio matutino:

Sugerir al paciente dar informacion sobre un aperitivo nocturno

Confirmar la cantidad de insulina que toma el paciente antes de dormir

Sugerir al paciente dar la cantidad de horas dormidas

Sugerir al paciente dar informacion sobre el desayuno

Confirmar la cantidad de insulina que toma el paciente despues del desayuno

Sugerir al paciente que tome la medida de bG antes del ejercicio

Sugerir al paciente que tome la medida de bG despues del ejercicio

Sugerir al paciente dar informacion sobre el tipo y la cantidad de ejercicio

Tfpicamente, se requiere que el paciente tome las medidas de bG de una prueba TIPs dentro de una ventana de tiempo que encapsula el evento dado (por ejemplo, dentro de una hora antes y despues del ejercicio). Para construir una prueba estructurada, el paciente selecciona el criterio contextual aplicable al paciente. Se observa que algunos de los criterios contextuales pueden estar relacionados con diferentes eventos, como el dormir o el desayuno, que pueden ocurrir fuera de la ventana para tomar las medidas de bG.

Alternativamente, puede ser mas intuitivo que el paciente comience seleccionando un objetivo para la prueba estructurada como se muestra en la figura 5B. Por ejemplo, el paciente puede desear conocer el efecto de comer un aperitivo o el efecto del ejercicio en una medida particular. En una realizacion, el paciente puede presentarse en 53 con una pluralidad de objetivos de prueba diferentes. A continuacion, el paciente selecciona un objetivo de la lista de diferentes objetivos de prueba que es capturado en 54 por el controlador para diabetes. El paciente tambien puede especificar un tipo de medicion particular. Dado el objetivo de prueba y/o la entrada del tipo de medicion por el paciente, el controlador para diabetes determina una plantilla de prueba propuesta como se indica en 55. En una realizacion de ejemplo, cada combinacion de objetivos de prueba y mapas de tipo de medicion a una plantilla de prueba propuesta almacenada en el controlador para diabetes.

Dos ejemplos ilustran ademas como un objetivo de prueba seleccionado puede correlacionarse con una plantilla de prueba propuesta. En un primer ejemplo, el paciente puede desear comprender el efecto de comer un aperitivo nocturno en una medida de ayuno matutino. Para comprender el efecto del aperitivo, cada caso de muestra de la plantilla de prueba propuesta puede incluir los siguientes eventos:

Plantilla de prueba A

Sugerir al paciente que tome una medida de referencia de la bG antes de tomar el aperitivo

Sugerir al paciente dar informacion sobre el aperitivo

Sugerir al paciente que tome la insulina nocturna

Confirmar la cantidad de insulina tomada por el paciente

Sugerir al paciente dar la cantidad de horas dormidas

Confirmar el ayuno por el paciente

Sugerir al paciente tomar la medida de bG matutina

Dado el objetivo de la prueba, el paciente puede ser presentado ademas con una lista priorizada de los criterios contextuales relacionados con tomar aperitivos como se describe anteriormente.

En un segundo ejemplo, el paciente puede desear comprender el efecto del ejercicio en una medida del ayuno matutino. En este caso, el objetivo de la prueba se correlaciona con una plantilla de prueba diferente. Cada instancia de muestra de la plantilla de prueba propuesta puede incluir los siguientes eventos:

5

10

15

20

25

30

35

40

45

50

55

60

65

Plantilla de prueba B

Sugerir al paciente que tome una medida de referencia de la bG antes de hacer ejercicio

Sugerir al paciente dar informacion sobre el ejercicio

Sugerir al paciente que tome la insulina nocturna

Confirmar la cantidad de insulina tomada por el paciente

Sugerir al paciente dar la cantidad de horas dormidas

Confirmar el ayuno por el paciente

Sugerir al paciente tomar la medida de bG matutina

De esta manera, la plantilla de prueba propuesta esta relacionada con el objetivo de prueba seleccionado por el paciente. Del mismo modo, se le puede presentar al paciente con una lista de criterios contextuales relacionados con el ejercicio. Cuando se construye una prueba estructurada, el paciente puede seleccionar cual de los eventos y/o criterio contextual asociado con la plantilla de prueba propuesta son aplicables al paciente. Los criterios contextuales seleccionados por el paciente se reciben en 57 y luego se utilizan para construir 58 una prueba estructurada para el paciente como se describe adicionalmente a continuacion. Se preve que la seleccion de criterios contextuales presentados al usuario puede ser un subconjunto de criterios contextuales que son filtrados o preseleccionados a partir de una gran agrupacion de criterios teniendo en cuenta el objetivo identificado.

Dado un conjunto de criterios contextuales seleccionados por el paciente, el sistema puede sugerir ademas al paciente dar informacion adicional relacionada con los criterios contextuales. Por ejemplo, si el paciente selecciono los criterios contextuales para comer un aperitivo, el sistema puede sugerirle al paciente que ingrese una hora o una ventana de tiempo en la que el paciente come el aperitivo. A su vez, el tiempo especificado se utiliza para programar un recordatorio apropiado para el paciente. Por ejemplo, si el paciente indica que su aperitivo nocturno ocurre tfpicamente entre las 8 pm y las 9 pm, entonces el sistema podna sugerir al paciente dar informacion sobre el aperitivo a las 9:15 pm. En otro ejemplo, el paciente puede indicar que el momento de su aperitivo nocturno vana, pero se va a dormir a las 11 pm. En este caso, el sistema podna sugerir al paciente dar informacion sobre el aperitivo justo antes de las 11 pm. Si el paciente no proporciona la informacion solicitada, el sistema puede sugerir al paciente dar la informacion en un momento posterior (por ejemplo, la manana siguiente antes o en el momento de la medicion de bG). Se entiende facilmente que este enfoque de programacion podna extenderse a otros tipos de criterios contextuales. Alternativamente, el paciente puede elegir un enfoque menos intrusivo por el cual se obtiene informacion contextual del paciente en el momento de la medicion de bG. En cualquier caso, el sistema permite al paciente configurar cuando y como se le sugiere al paciente que introduzca informacion contextual relacionada con la medicion de bG.

La prueba estructurada se construye de acuerdo con la plantilla de prueba propuesta, incluyendo los diversos criterios contextuales e informacion asociada especificada por el paciente. En primer lugar, la prueba estructurada incluina diversos eventos obligatorios como se especifica en la prueba propuesta. Continuando con la medida de ayuno matutino establecida anteriormente, la prueba estructurada para el ayuno matutino incluina una sugerencia para que el paciente tome la insulina nocturna, una pregunta confirmando la cantidad de insulina tomada por el usuario, una pregunta confirmando que el paciente ha estado ayunando, y una sugerencia para que el paciente tome la medida de bG matutina. Cada uno de estos eventos tendna un horario asociado.

En una realizacion simplificada, la prueba estructurada incluina ademas eventos opcionales seleccionados por el paciente. Cada evento puede estar asociado con una lista predefinida de criterios contextuales. Cada criterio a su vez corresponde a o se traduce a una o mas preguntas que se presentan al paciente con el proposito de recolectar datos contextuales asociados con la medida de bG. En otra realizacion, el paciente esta presente con una lista priorizada de criterios contextuales. Cada criterio contextual seleccionado de la lista por el paciente se traduce a una o mas consultas que se presentan al paciente. En cualquier realizacion, las preguntas correspondientes se convierten en eventos en la prueba estructurada. Las respuestas a las preguntas son capturadas por el sistema y almacenadas con las medidas de bG correspondientes. Cada evento y/o criterio tendna un horario predeterminado para las preguntas asociadas.

Continuando con la medida del ayuno matutino, el paciente puede haber seleccionado eventos relacionados con un aperitivo nocturno pero no relacionado al ejercicio. En este caso, la prueba estructurada incluina una o mas preguntas al paciente con respecto a su aperitivo nocturno (por ejemplo, que tipo de alimento se comio, cual era el tamano de la porcion, cuantos carbohidratos se consumfan, etc.). Ademas, estas preguntas tendnan un horario predeterminado asociado (por ejemplo, inmediatamente antes de que le sea sugerido al paciente que tome la medida de bG matutina). Dado este escenario de ejemplo, la prueba de estructura especificada por el usuario puede definirse como sigue:

5

10

15

20

25

30

35

40

45

50

55

60

65

Prueba de estructura de ayuno matutino

Evento Sugerir al paciente tomar la insulina nocturna: Horario 6 de marzo a las

Preguntar la cantidad de insulina: 6 de marzo a las

Confirmar el ayuno: 7 de marzo a las

Sugerir al paciente que tome la medida de bG: 7 de marzo a las

Preguntar al paciente sobre el aperitivo nocturno: 7 de marzo a las

10:00 pm 10:00 pm 8:00 am 8:00 am 8:00 am

En este escenario, el paciente especifico una medida de ayuno matutino para ocurrir el 7 de marzo. Al seleccionar el evento para comer un aperitivo nocturno, el paciente puede haber indicado ademas el momento de su aperitivo nocturno y/o la hora de acostarse, de tal forma que los eventos se programan acordemente. Se preve que la regulacion del tiempo de los eventos que comprenden la prueba estructurada tambien puede ser configurada directamente por el paciente o programada automaticamente por el sistema con base en la informacion aprendida previamente del paciente. La prueba estructurada definida por el usuario es almacenada por el controlador para diabetes para su posterior ejecucion por el paciente. Una vez que una prueba ha sido definida por el paciente, se puede seleccionar y volver a ejecutar varias veces a peticion del paciente.

En una realizacion mas solida, los criterios contextuales seleccionados por el paciente sirven como criterios de adherencia para la prueba estructurada. Los criterios de adherencia describen las condiciones bajo las cuales la prueba estructurada se administra al paciente. Para una medida de ayuno matutina, un criterio de adherencia de ejemplo es si el paciente ha estado ayunando durante al menos 8 horas antes de la medida de bG. Antes de tomar una medida de bG, el sistema puede sugerir al paciente que confirme que estaba ayunando. Con una respuesta afirmativa del paciente, se satisface el criterio de adherencia. La confirmacion del ayuno puede ser un criterio requerido para la medida del ayuno matutino. Al construir la prueba estructurada, el paciente tambien puede haber seleccionado el criterio contextual de la plantilla de prueba propuesta. De igual forma, el sistema preguntara al paciente la informacion contextual asociada con el criterio seleccionado. El criterio seleccionado puede funcionar como criterio de adherencia para la prueba estructurada. Es decir, los datos de muestra adquiridos bajo una prueba estructurada dada solo se consideraran aceptables cuando se cumplan todos los criterios de adherencia para la prueba estructurada dada. En el contexto de la medida del ayuno matutino, el paciente puede haber seleccionado un criterio contextual relacionado con un aperitivo nocturno. Por lo tanto, los datos de muestra de una instancia de muestra dada de la prueba estructurada definida por el usuario se consideraran aceptables cuando el paciente confirme el ayuno y proporcione informacion sobre su aperitivo nocturno. Si el paciente no proporciona informacion sobre su aperitivo nocturno, los datos de muestra de la instancia de muestra se marcan como inaceptables o descartados por el sistema.

Ademas, los valores asociados a un criterio contextual seleccionado tambien pueden servir como un segundo nivel de criterios de adherencia. Por ejemplo, confirmar la toma de insulina puede ser un criterio de adherencia de primer nivel para una prueba dada. Antes de o en el momento en que se administra una prueba por primera vez, se puede sugerir al usuario que introduzca una cantidad particular de insulina tomada. En respuesta, el usuario puede especificar que 30 unidades de insulina fueron tomadas. En este ejemplo, el valor de entrada de 30 puede servir como un criterio de adherencia secundaria para esta prueba. Se pedira al usuario que confirme la cantidad de insulina tomada o se le pregunta introducir la cantidad de insulina que se toma cada vez que se administra esta prueba en el futuro. Si el usuario no confirma que se tomaron 30 unidades de insulina o ingresa una cantidad diferente de 30, entonces los datos de muestra de la instancia de muestra pueden marcarse como inaceptables por no cumplir con estos criterios de adherencia secundaria, ya que el contexto entre las dos instancias de muestra vana. Aunque ambas instancias de muestra son validas, no deben compararse directamente entre sf sin destacar las diferencias. Se preve que los criterios contextuales pueden ser designados de antemano por los disenadores del sistema como criterios de adherencia para la prueba estructurada o designados como tales por el paciente mientras se define la prueba estructurada. Tambien se preve que otros tipos de criterios de prueba, como los criterios de entrada o los criterios de salida, tambien pueden asociarse a una prueba estructurada. Se pueden encontrar mas detalles con respecto a diferentes tipos de criterios de prueba, asf como el modo en que se implementan dichos criterios, en las Publicaciones de Patente de los Estados Unidos Nos. 2010/0212675 y 2010/0218132 que se incorporan aqrn como referencia.

La Figura 6 representa un metodo de ejemplo para implementar una prueba estructurada para el paciente por parte del controlador para diabetes. Una pluralidad de pruebas estructuradas diferentes, incluyendo las construidas por el paciente de la manera expuesta anteriormente, se pueden almacenar en el controlador para diabetes. Una lista de pruebas estructuradas disponibles puede ser presentada en una pantalla para su seleccion por el paciente. Al seleccionar una prueba estructurada dada, el paciente puede especificar en 61 el momento para la ejecucion de la prueba. Por ejemplo, una medida de ayuno matutina ocurrira manana por la manana. Con base en el tiempo

5

10

15

20

25

30

35

40

45

50

55

60

65

especificado para la prueba, cada uno de los eventos asociados con la prueba estructurada estan programados en 62 por el controlador para diabetes. Durante la ejecucion de la prueba, los eventos se ejecutan a continuacion en 63 de acuerdo con el horario de eventos. Para cada evento ejecutado, el controlador para diabetes recopila y registra los datos asociados con el evento. Los datos recolectados durante la prueba estructurada se identifican de forma unica por prueba y/o evento para propositos de informes posteriores.

Despues de que los eventos de prueba se han ejecutado, los criterios de adherencia para la prueba estructurada se evaluan en 64. Mas espedficamente, cada criterio de adherencia es evaluado por el controlador para diabetes. Los datos de la muestra, incluidas las mediciones de bG, adquiridas bajo la prueba estructurada, se consideran aceptables cuando se cumplen todos los criterios de adherencia para la prueba estructurada. En este caso, los datos de la muestra se conservan para su posterior analisis y se informan al paciente o a su proveedor de atencion sanitaria. Si no se cumple uno o mas de los criterios de adherencia, los datos de la muestra pueden ser descartados o marcados de otra manera como no conformes con los requisitos de la prueba. En otros casos, el procedimiento de prueba puede interrumpirse cuando no se cumple un criterio de adherencia. Por ejemplo, en un ayuno matutino, puede no sugerirsele al paciente proporcionar una muestra de sangre si no ha ayunado una cantidad suficiente de tiempo. Cuando la prueba estructurada se compone de instancia de muestra unica (es decir, una medida de glucosa o una prueba de TIPs), entonces la prueba estructurada esta completa. Es de destacar que una vez que el paciente ha construido una prueba de estructura, la prueba se puede ejecutar repetidamente sin modificaciones a sus parametros especificados por el usuario. Es decir, los criterios contextuales seleccionados por el paciente se llevan adelante cuando la prueba se ejecuta en el futuro. Se entiende que el controlador para diabetes puede respaldar modificaciones por el paciente a una prueba estructurada dada, tal como la adicion o supresion del criterio contextual. Tambien se entiende que solo se discuten los pasos relevantes de la metodologfa en relacion con la figura 6, pero que pueden ser necesarias otras instrucciones implementadas por software para controlar y gestionar la ejecucion de una prueba de estructura por el sistema.

Las pruebas estructuradas, hasta ahora, han sido presentadas como estando compuestas por una sola instancia de muestra. Muchas veces, las plantillas de prueba recomiendan o requieren la adquisicion de multiples instancias de muestra durante un penodo de tiempo. Por ejemplo, una plantilla de prueba puede solicitar instancias de muestra durante un penodo de dfas, semanas o meses para comprender completamente el efecto de comer un aperitivo sobre una medida de ayuno matutino. Estas instancias de muestra se denominan colectivamente como un grupo de muestras. Para estos tipos de prueba estructurada, los criterios de adherencia definidos para una instancia de muestra se llevan adelante a cada muestra en la prueba. Tambien se pueden definir criterios de adherencia para un grupo de muestras y/o para la prueba general.

Ademas, al definir una prueba, el usuario puede especificar la frecuencia de repeticion de la prueba. Por ejemplo, el usuario puede especificar que una prueba dada ocurra diariamente, semanalmente o en otros intervalos de tiempo recurrentes. Los criterios contextuales definidos por el usuario se trasladaran a cada instancia de muestra de dichas pruebas recurrentes. De esta manera, se pueden adquirir, analizar y reportar al usuario multiples medidas de glucosa adquiridas en un contexto similar.

En otro aspecto de la divulgacion, el paciente puede especificar adicionalmente el tipo de prueba. Mas espedficamente, se puede pedir al paciente que clasifique el tipo de prueba en el momento en que se construye o administra la prueba. Tipos de prueba de ejemplo pueden incluir, pero no estan limitados a, un tipo de prueba “tipico”, “atfpico” o “delta”. Cada uno de estos tipos de prueba se describen adicionalmente a continuacion.

Dado un escenario en el que un paciente esta tratando de entender mejor el efecto de un aperitivo en su medida de ayuno matutino, el sistema permite al paciente categorizar mas y asf comparar datos de muestra adquiridos en una prueba estructurada espedfica o a traves de pruebas estructuradas similares. Por ejemplo, suponga que el paciente normalmente come dos cucharadas de helado cada noche. Durante la ejecucion de una instancia de muestra, se pide al paciente que categorice aun mas la instancia de muestra como tfpica o atfpica. Los datos de muestra adquiridos durante la prueba pueden ser etiquetados en consecuencia. Dado un numero suficiente de casos de muestra, el sistema podna proporcionar al paciente con informacion sobre el efecto de este aperitivo tfpico en su medida de ayuno matutino (en comparacion, por ejemplo, con las medidas de referencia donde el paciente no coirna un aperitivo nocturno). En el caso de que el paciente no haya establecido una medida de referencia para el ayuno de la manana sin haber comido un aperitivo nocturno, los datos de la muestra para el aperitivo tfpico se almacenan hasta que se haya adquirido un numero suficiente de muestras para establecer la medida de referencia. El sistema podna entonces analizar retroactivamente y reportar informacion sobre el efecto del aperitivo tfpico en la medida de ayuno matutino.

Los pacientes pueden variar de su merienda tfpica de vez en cuando. La varianza puede incluir pero no se limita al tipo de alimento, la cantidad de alimento o la hora en la que se comio el alimento. En este caso, el paciente puede especificar la instancia de ejemplo como “atfpica” cuando se le pide que categorice la instancia de muestra. Se puede sugerir al paciente etiquetar o describir el tipo de varianza. Los datos de muestra adquiridos durante la instancia de muestra se etiquetaran en consecuencia. El sistema puede ignorar los datos de la muestra etiquetados como "atfpicos" al analizar e informar sobre el efecto del aperitivo tfpico en la medida del ayuno matutino. Alternativamente, los datos de muestra marcados como "atfpicos" pueden compararse con otros casos atfpicos de

5

10

15

20

25

30

35

40

45

50

55

60

65

construccion similar. Si se adquiere un numero suficiente de ejemplos de muestras para una variante particular (por ejemplo, diez casos en que el paciente comio pizza en lugar de helado o comio tres cucharadas en lugar de dos cucharadas de helado), el sistema podna proporcionar al paciente informacion sobre el efecto de este bocado atipico particular en su medida del ayuno matutino.

En una prueba "delta", el paciente quisiera entender el efecto de un cambio en su aperitivo en su medida del ayuno matutino. En consecuencia, el sistema guiana al paciente a traves de un numero de instancias de muestra tomadas en un primer contexto (o antes). Despues de establecer una medida de referencia, el sistema sugerina al paciente a realizar un cambio en la variable bajo prueba, tal como su aperitivo nocturno. El sistema entonces guiana al paciente a traves de una serie de instancias de muestra adicionales tomadas en el contexto cambiado (o despues). Con base en los datos de muestra recolectados, el sistema podna proporcionar al paciente informacion sobre el efecto del cambio en su medida de glucosa en sangre.

Se exponen otros escenarios que ilustran como estos conceptos se combinan para proporcionar una interfaz robusta que permite al paciente entender mejor los factores que afectan las medidas de glucosa en sangre. En un primer escenario, a un usuario le gustana ver el efecto en su ayuno de comer un aperitivo grande antes de acostarse. El usuario tfpicamente come un aperitivo pequeno. Para ello, el usuario selecciona un objetivo de prueba (es decir, variable bajo prueba) como una "medida de ayuno matutino" con acoplamiento de comida. El usuario puede especificar ademas el tipo de prueba como un tipo de prueba “delta”. Para facilitar la configuracion de la prueba, el sistema le sugiere al usuario varias entradas. Por ejemplo, el sistema le sugiere al usuario cuando debe medir el ayuno. El sistema le sugiere al usuario cuando va a ocurrir la ingesta de comida, con un valor predeterminado la noche anterior. El sistema opcionalmente puede sugerir al usuario dar la cantidad de carbohidratos (intervalo) que un aperitivo pequeno implicara, asf como la cantidad de carbohidratos (intervalo) que el aperitivo grande implicara. A continuacion, el usuario establece una fecha de inicio para la prueba (el valor predeterminado es inmediato) e identifica cuando se debe ejecutar (por ejemplo, dfas laborables, fines de semana, continua, a peticion).

A la hora especificada de la comida, el sistema le avisa al usuario que consuma un pequeno aperitivo. A medida que el sistema entiende que se trata de una instancia de comida, solicita que el usuario ingrese la cantidad de carbohidratos. Si el usuario no especifico previamente el intervalo previsto, el sistema utiliza el primer valor introducido por el usuario para establecer un intervalo probable (por ejemplo, establecido en + numeros fijos de carbohidratos del valor de entrada). El sistema puede sugerir al usuario tomar su terapia (como la insulina o un agente antidiabetico oral) y confirma la administracion. A la manana siguiente, el sistema pregunta al usuario si ha estado ayunando desde su aperitivo nocturno. Tras la confirmacion de ayuno, el sistema sugiere al usuario que proporcione una muestra de sangre y, de este modo, adquiere un valor de bG. El sistema repite este proceso en los intervalos de tiempo especificados hasta que se establezca la variabilidad asociada con esta accion. Una vez establecida la variabilidad, el sistema solicitara el nuevo tamano del aperitivo y repetira el proceso hasta que se establezca la variabilidad asociada con el nuevo tamano del aperitivo. Al finalizar, el sistema genera y envfa un informe al usuario. De esta manera, el usuario puede comprender mejor el efecto del tamano de su aperitivo sobre sus medidas de glucosa en sangre.

En un segundo escenario, un usuario diabetico tipo 1 deseana ver el efecto de cambiar el tiempo en su dosis prealimento de insulina de accion rapida. El usuario piensa que su medida postprandial de 2 horas es demasiado alta. El usuario no quiere que el sistema evalue el cambio, pero quiere hacerlo por sf mismo. Por lo tanto, el usuario define una prueba para evaluar este escenario. En este caso, el usuario selecciona el objetivo de prueba como "comida pre-post" y selecciona el tipo de prueba como prueba "atfpica". El sistema entiende que el usuario esta en la terapia bolo-basal de insulina. Le sugiere al usuario que identifique que variable esta modificando (como la cantidad de bolo, la hora del bolo, la cantidad basal, el tamano de la comida, el ejercicio antes de la comida). El usuario puede seleccionar el tiempo del bolo, y el sistema pide la compensacion que el usuario va a usar. Esto se convierte en un metodo de seguimiento para futuras revisiones. Si el usuario utiliza el enfoque TIP convencional, despues de que se presentan los datos, se vuelve inutil (es decir, el usuario no atribuira el tipo de prueba a nada, por lo tanto no tiene ningun valor). Por el contrario, el sistema presentado en esta divulgacion respaldara la revision historica y la comparacion de pruebas similares.

Durante la prueba, el sistema primero sugiere al usuario que adquiera su medida de bG. El sistema entonces le sugiere al usuario que administre su insulina y confirme la cantidad de insulina. El sistema puede sugerirle al usuario que introduzca el tamano de la comida y le sugiere al usuario que comience a comer. Despues de comer, el sistema le pide al usuario que adquiera el valor de bG de seguimiento. Si el usuario desea comparar resultados de dos grupos de muestras diferentes, el sistema permite al usuario seleccionar dos grupos de muestras almacenados que tienen los mismos parametros de prueba para su revision y comparacion.

En un escenario relacionado, el usuario puede querer evaluar un intervalo de tiempo de administracion antes de la comida, que va desde 20 minutos antes a 10 minutos despues en incrementos de 5 minutos. En este caso, el usuario especificara el tipo de prueba como “variable”. El usuario establece la fecha de inicio (el valor predeterminado es inmediato) e identifica cuando se debe ejecutar (dfas de semana, fines de semana, continuo, a peticion) y a que comidas (desayuno, almuerzo, cena, aperitivo, todo) se aplica la prueba. El sistema entonces secuencia el usuario que comienza de 0 al extremo.

5

10

15

20

25

30

35

40

45

50

55

60

65

La figura 7 ilustra casos de uso de ejemplo para informar los resultados de las pruebas. Los informes de casos de uso se describen en el contexto de las pruebas TIPs, pero se pueden ampliar a otros tipos de estructuras de pruebas. Tenga en cuenta que los criterios contextuales son necesarios para comprender las medidas y son aplicados por el sistema de la manera discutida anteriormente; mientras que los atributos son informacion que el usuario considera util y se proporciona a discrecion del usuario. Se entiende facilmente que el sistema puede estar configurado para respaldar tales casos de informes de uso.

Se pueden proporcionar informes para comparar eventos. Por ejemplo, el sistema puede proporcionar o informar una comparacion de eventos similares. Los eventos se pueden considerar similares cuando uno o mas criterios contextuales para la instancia de muestra adquirida son los mismos. Otros medios para evaluar la similitud de los acontecimientos o el contexto bajo el cual se adquirieron instancias de muestra se contemplan en esta divulgacion. La presentacion de informes sobre eventos similares puede incluir destacar similitudes y/o diferencias en el contexto de las pruebas.

En otras situaciones, se espera que los eventos sean diferentes. Esto ocurre cuando una instancia TIP se vuelve a ejecutar en modo atfpico. En este caso, el sistema destaca las diferencias en los contextos y muestra el efecto neto sobre la varianza de la medida de bG resultante. Por ejemplo, el usuario quiere evaluar ad hoc el efecto de comer un desayuno en su bG antes del almuerzo. Tfpicamente no come desayuno. El usuario crea una prueba en la que anaden el criterio de tamano de la comida del desayuno a la comida del almuerzo. El sistema muestra dos almuerzos. Uno con un tamano de la comida de desayuno de 0, comparado con un tamano de la comida de digamos 35 carbohidratos. Estos valores, asf como los valores de bG resultantes se resaltan en comparacion con otros atributos/contextos establecidos a traves de otras instancias TIP similares.

En otro ejemplo, el usuario come regularmente el desayuno, cada uno con consumos de carbohidratos ligeramente diferentes. El usuario ha tomado varios ejemplos TIP. El sistema muestra las diferentes instancias TIP similares y resalta los diferentes tamanos de comida y los valores de bG resultantes. Alternativamente, el usuario come regularmente el desayuno, cada uno con ligeramente diferentes consumos de carbohidratos. El usuario ha tomado diferentes cantidades de insulina basal a traves de varias instancias TIP. El usuario desea ver las diferencias en las medidas de bG resultantes. El sistema muestra al usuario las pruebas similares, y destaca las diferencias en las cantidades de insulina basal y el tamano de la comida frente a la medida de bG resultante.

Se puede proporcionar informacion sobre la variabilidad del evento. En este caso, el usuario desea evaluar la variabilidad en la bG con base en un evento similar ejecutado. El usuario esta haciendo esto para ver la variabilidad de la base que tiene (o que come regularmente la misma comida). En este caso, el sistema impone el tamano de la comida consumida (adherencia de segundo nivel) y tomara multiples instancias TIP con el proposito de evaluar la variabilidad como medida estadfstica. Por ejemplo, el usuario come regularmente una comida de pollo a la parrilla a la hora del almuerzo, y quiere ver la variabilidad de su valor despues de la comida. El sistema sugiere al usuario cada hora de almuerzo tomar el valor TIP, e impone el segundo nivel de adherencia. En este caso, el sistema no informa sobre el contexto, sino sobre la variabilidad, incluyendo la medida de bG promedio, el intervalo y potencialmente otras medidas estadfsticas (como la mediana, maximo, mmimo y desviacion estandar). Usando este ejemplo, el usuario sera "introducido por si mismo" al acoplamiento de comida; el efecto de la comida del desayuno sobre el resultado de la comida del almuerzo. Los informes sobre variabilidad aplicados a eventos similares o a un grupo de muestra tambien pueden extenderse y aplicarse a grupos de muestras multiples. Los grupos de muestras se evaluan primero en cuanto a la similitud y, si son similares, se evaluan adicionalmente para determinar la variabilidad entre los grupos de muestras similares. La variabilidad entre los grupos de muestras puede entonces ser reportada al usuario.

Dada la variabilidad de un grupo de muestra dado, el sistema puede respaldar funcionalidad adicional relacionada con la administracion de la prueba estructurada asociada. Por ejemplo, cuando la variabilidad es baja (por ejemplo, la desviacion estandar es menor que un umbral predefinido), se puede permitir al usuario modificar el evento y/o los criterios contextuales (por ejemplo, cambiar el numero de carbohidratos consumidos en una comida) porque cualquier cambio en la bG sera atribuible a la modificacion y no a la variabilidad en el grupo de muestra. Cuando la variabilidad es alta, el sistema no puede permitir al usuario modificar el evento porque cualquier cambio no puede ser distinguible de las instancias de la muestra y por lo tanto no sena necesariamente atribuible a la modificacion del evento. El sistema puede evaluar adicionalmente la cantidad de instancias de muestra que comprenden el grupo de muestras e informar al usuario que se necesitan mas instancias de muestra para respaldar informes precisos. Otras formas de reconfigurar el protocolo con base en la variabilidad tambien se contemplan en esta divulgacion.

Tambien se puede proporcionar informacion sobre el cambio de evento. En este caso, el usuario tiene un evento regular, y tiene la intencion de cambiar el evento. El usuario desea ver el efecto del cambio. Por ejemplo, el usuario corre regularmente 4 millas por dfa. El usuario quiere subir su distancia en millas a 5 millas diarias, y quiere ver el efecto en la medida de bG post carrera. Para una evaluacion ad hoc, el usuario solo puede comparar dos instancias TIP. Sin embargo, si el usuario desea mas precision en su evaluacion, puede examinar la variabilidad. En este ejemplo, el sistema compara muchas carreras anteriores de 4 millas (ya sea retrospectivamente porque existen, o en perspectiva, pidiendo al usuario que ejecute un numero predeterminado de carreras de 4 millas). A continuacion, el sistema sugiere el aumento en la distancia en millas. El informe resultante muestra una comparacion estadfstica con

5

10

15

20

25

30

las dos carreras diferentes, incluyendo el cambio en la media/mediana, si el cambio fue real (prueba t o equivalente), y similares. Se entiende facilmente que otro caso de uso de informes puede ser desarrollado y respaldado por el sistema.

Tal como se usa aqm, el termino modulo puede referirse a, ser parte de, o incluir un Circuito Integrado de Aplicacion Espedfica (ASIC); un circuito electronico; un circuito logico combinatorio; una matriz de portal programable de campo (FPGA); un procesador (compartido, dedicado o grupo) que ejecuta codigo; otros componentes adecuados que proporcionan la funcionalidad descrita; o una combinacion de algunas o todas las anteriores, como en un sistema sobre chip. El termino modulo puede incluir memoria (compartida, dedicada o de grupo) que almacena codigo ejecutado por el procesador.

El termino codigo, tal como se utilizo anteriormente, puede incluir software, firmware y/o microcodigo, y puede referirse a programas, rutinas, funciones, clases y/u objetos. El termino compartido, como se utilizo anteriormente, significa que algunos o todo el codigo de varios modulos puede ejecutarse utilizando un unico procesador (compartido). Ademas, algunos o todo el codigo de modulos multiples puede ser almacenado por una sola memoria (compartida). El termino grupo, tal como se utilizo anteriormente, significa que algunos o todo el codigo de un solo modulo puede ejecutarse utilizando un grupo de procesadores. Ademas, algunos o todo el codigo de un solo modulo puede almacenarse utilizando un grupo de memorias.

Los aparatos y metodos descritos aqm pueden implementarse mediante uno o mas programas de ordenador ejecutados por uno o mas procesadores. Los programas informaticos incluyen instrucciones ejecutables por el procesador que se almacenan en un medio tangible no transitorio legible por ordenador. Los programas informaticos tambien pueden incluir datos almacenados. Ejemplos no limitativos del medio tangible no transitorio legible por ordenador son memoria no volatil, almacenamiento magnetico y almacenamiento optico.

La descripcion anterior de las realizaciones se ha proporcionado con fines de ilustracion y descripcion. No pretende ser exhaustiva ni limitar la divulgacion. Los elementos o caractensticas individuales de una realizacion particular no estan generalmente limitados a esa realizacion particular, pero, donde sea aplicable, son intercambiables y pueden usarse en una realizacion seleccionada, incluso si no se muestra o describe espedficamente. Lo mismo puede ser variado de muchas maneras. Tales variaciones no deben considerarse como un alejamiento de la divulgacion, y todas estas modificaciones estan destinadas a ser incluidas dentro del alcance de la divulgacion.

Claims

5

10

15

20

25

30

35

40

45

50

55

60

65

REIVINDICACIONES

1. Un metodo para medirlos niveles de glucosa de un paciente, que comprende:

- recibir (54) del paciente un objetivo para una prueba estructurada;

- identificar (55) una plantilla de prueba que corresponde al objetivo a partir de una pluralidad de plantillas de prueba predefinidas, en la que la plantilla de prueba esta compuesta por multiples instancias de muestra durante un penodo de tiempo, siendo las instancias multiples de muestreo una medicion de glucosa o un par de mediciones de glucosa en sangre antes y despues de un evento, y las multiples instancias de muestra que proporcionan un grupo de muestras;

- presentar (56) al paciente con una pluralidad de criterios contextuales para la plantilla de prueba identificada;

- recibir (57) la seleccion de uno o mas criterios contextuales asociados con el evento por el paciente de la pluralidad de criterios contextuales;

- construir (58) una prueba estructurada que incluya el criterio contextual seleccionado por el paciente y de acuerdo con la plantilla de prueba identificada; y

- administrar la prueba estructurada al paciente, incluyendo

- sugerir al paciente proporcionar una muestra de sangre a un medidor de glucosa;

- recolectar los datos que incluyan datos de medicion de glucosa en sangre;

- presentar una pregunta al paciente para cada criterio contextual;

- recibir respuestas a las preguntas de parte del paciente; y

- asociar las respuestas con los datos recolectados durante la prueba estructurada;

de manera que las etapas del metodo son implementadas por un procesador de ordenador de un dispositivo; Caracterizada porque

- la pluralidad de criterios contextuales presentados al usuario que son un subconjunto de criterios contextuales que son filtrados o preseleccionados por el procesador del ordenador a partir de un grupo grande de criterios contextuales teniendo en cuenta el objetivo para la prueba estructurada;

- determinar una variabilidad del grupo de muestras; y

- cuando, mientras que la prueba estructurada se administra al usuario, la variabilidad es inferior a un umbral predeterminado que permite una modificacion de los criterios contextuales y cuando, mientras la prueba estructurada se administra al usuario, la variabilidad es mayor que el umbral predeterminado no permitiendo una modificacion de los criterios contextuales.
2. El metodo de la reivindicacion 1, que comprende ademas presentar al paciente con una pluralidad de objetivos para llevar a cabo una prueba estructurada, de manera que cada uno de los objetivos se correlacione con una de una pluralidad de plantillas de prueba.
3. El metodo de la reivindicacion 1 o 2, que comprende ademas presentar al paciente con un conjunto de criterios contextuales para la plantilla de prueba seleccionada de tal manera que un criterio contextual asociado con una plantilla de prueba dada difiere de un criterio contextual asociado con otra plantilla de prueba entre la pluralidad de plantillas de prueba predefinidas.
4. Un dispositivo controlador para diabetes, que comprende:

- un modulo de configuracion de prueba configurado para recibir (54) un objetivo para una prueba estructurada de un usuario del dispositivo y operable para identificar (55) una plantilla de prueba que corresponde al objetivo a partir de una pluralidad de plantillas de prueba predefinidas, el modulo de configuracion de prueba en comunicacion de datos con una presentacion del dispositivo para presentar (56) una pluralidad de criterios contextuales para la plantilla de prueba identificada y operable para recibir (57) la seleccion de uno o mas criterios contextuales por parte del usuario de la pluralidad de criterios contextuales,en donde la plantilla de prueba esta compuesta de multiples instancias de muestras durante un penodo de tiempo, siendo las instancias multiples de muestra una medicion de glucosa o un

5

10

15

20

25

30

35

40

par de mediciones de glucosa en sangre antes y despues de un evento y las multiples instancias de muestra que proporcionan un grupo de muestras;

- un modulo constructor de prueba configurado para recibir (57) el criterio contextual asociado con el evento y seleccionado por el usuario y construir (58) una prueba estructurada que incluye el criterio contextual seleccionado por el usuario y de acuerdo con la plantilla de prueba identificada;

- un modulo de administracion de prueba operable para administrar la prueba estructurada a un paciente, y ademas operable para presentar una pregunta al usuario para cada criterio contextual, para recibir respuestas a las preguntas del usuario y asociar las respuestas con datos de medicion de glucosa sangumea recolectados durante la prueba estructurada; y

- un modulo de medicion de glucosa en sangre que mide selectivamente la glucosa en sangre en una muestra de sangre;

en el que el modulo de configuracion de prueba, el modulo constructor de prueba y el modulo de administracion de prueba estan implementados como instrucciones ejecutables por ordenador por un procesador de ordenador del dispositivo, caracterizado porque

- la pluralidad de criterios contextuales presentados al usuario siendo un subconjunto de criterios contextuales que son filtrados o preseleccionados por el procesador del ordenador a partir de un grupo grande de criterios contextuales teniendo en cuenta el objetivo de la prueba estructurada;

- determinar la variabilidad del grupo de muestras; y

- cuando, mientras que la prueba estructurada se administra al usuario, la variabilidad es inferior que un umbral predeterminado que permite una modificacion de los criterios contextuales y cuando, mientras la prueba estructurada se administra al usuario, la variabilidad es mayor que el umbral predeterminado no permitiendo una modificacion de los criterios contextuales.
5. El dispositivo controlador para diabetes de la reivindicacion 4, en el que el modulo de configuracion de prueba presenta al usuario con una pluralidad de objetivos para llevar a cabo una prueba estructurada, de manera que cada uno de los objetivos se correlaciona con uno de la pluralidad de plantillas de prueba predefinidas.
6. El dispositivo controlador para diabetes de una cualquiera de las reivindicaciones 4 o 5, en el que el modulo de configuracion de prueba presenta al usuario un conjunto de criterios contextuales para la plantilla de prueba seleccionada de tal manera que un criterio contextual asociado con una plantilla de prueba dada difiere de un criterio contextual asociado con otra plantilla de prueba entre la pluralidad de plantillas de prueba predefinidas.