ES2733350T3 - Sistema para el diagnóstico, tratamiento y pronóstico médicos para acontecimientos solicitados y procedimiento del mismo - Google Patents

Abstract

Un procedimiento computarizado para ayudar a garantizar que la selección de una opción sea pertinente para lograr un objetivo del tratamiento de un paciente con diabetes, comprendiendo el procedimiento: especificar por medio de un dispositivo de introducción de datos (36, 40) de un ordenador (14) uno o más protocolos de obtención de datos contenidos en un módulo de protocolos de obtención de datos (70) que abordan necesidades de diagnóstico y tratamiento específicas del paciente con diabetes; seleccionar por medio del dispositivo de introducción de datos (36, 40) del ordenador (14) un modelo de paciente disponible en un módulo de modelos de paciente (72) que modela matemáticamente uno o más aspectos de la fisiología humana definidos en ecuaciones diferenciales; realizar un análisis sobre el modelo de paciente seleccionado por medio de la ejecución de submódulos del módulo de modelos de paciente en el ordenador (14) que determina parámetros del modelo de paciente seleccionado empleando técnicas de ajuste de datos; realizar una verificación del modelo de los parámetros determinados por medio de un módulo de validación del modelo (74) que se ejecuta en el ordenador, lo que garantiza que el modelo de paciente seleccionado haya capturado la dinámica apropiada que aborda las necesidades de diagnóstico y tratamiento específicas del paciente; y caracterizado por, introducir en el ordenador (14) datos específicos del paciente obtenidos por un dispositivo externo (48) según el uno o más protocolos de obtención de datos especificados en los que el ordenador (14) comprueba la calidad de los datos específicos del paciente obtenidos con un procedimiento de calidad de los datos en forma de un módulo matemático que examina la calidad de los datos obtenidos en términos de su rendimiento y/o propiedades estadísticas y proporciona en un monitor (36) del ordenador (14) una serie de recomendaciones del tratamiento para el paciente, cada una con una clasificación de pertinencia que se basa en la selección del efecto de dicha recomendación del tratamiento en base a la calidad de los datos específicos del paciente obtenidos que tendrá en la generación de cambios en el tratamiento del paciente, aplicar los datos específicos del paciente al modelo de paciente seleccionado para generar parámetros del tratamiento a partir del modelo después de la selección de una de las recomendaciones del tratamiento, y realizar un análisis realizando simulaciones in silico para cuestionar los casos críticos en cuanto a la solidez del 35 tratamiento y evaluar la estabilidad de la solución por medio de un módulo de análisis (76) que se ejecuta en el ordenador (14) usando los datos específicos del paciente aplicados y el modelo de paciente seleccionado que proporciona en el monitor (36) del ordenador (14) al menos un tratamiento específico del paciente recomendado en base a parámetros del tratamiento que comprenden la tasa basal, la sensibilidad a la insulina y la proporción de carbohidratos con respecto a insulina generados a partir del modelo seleccionado para su aprobación.

Description

DESCRIPCIÓN

Sistema para el diagnóstico, tratamiento y pronóstico médicos para acontecimientos solicitados y procedimiento del mismo

La presente invención se refiere en general al control de enfermedades crónicas, y en particular a un sistema para el diagnóstico, tratamiento y pronóstico médicos computarizado y procedimiento del mismo que analiza la fisiología humana individual obtenida para ayudar a los médicos de cabecera en el diagnóstico de una enfermedad crónica del individuo, y que ofrece tratamientos específicos del paciente y el pronóstico de tratamientos sugeridos en base al análisis realizado usando una mezcla de segmentos de obtención de datos especializados, segmentos de análisis y segmentos de evaluación.

Tradicionalmente, los tratamientos se basan en pruebas clínicas y dispositivos de medición únicos para diagnosticar una enfermedad o dolencia. En su mayor parte, la intención de usar dichas pruebas y dispositivos es obtener una medición de calidad única. Dicha medición proporciona una instantánea. Sin embargo, se requiere una serie de mediciones para entender la dinámica del sistema y las características del sistema subyacentes de la enfermedad.

Una serie de mediciones claramente da como resultado más datos. Sin embargo, no siempre es fácil traducir dichos datos en información de utilidad clínica. De hecho, es una tarea que dista de ser trivial identificar qué problemas se pueden abordar y qué requisitos previos se necesitan para hacer que los datos más abundantes proporcionados por medición continua o frecuente sean útiles en la práctica de la medicina. Además, las compañías farmacéuticas realizan la tarea de caracterizar la actividad metabólica del fármaco y determinar la pauta de dosificación del fármaco. En general, las compañías farmacéuticas realizan elaborados ensayos clínicos para determinar la potencia de los fármacos y la eficacia de los fármacos para una población objetivo. Pero, estrictamente hablando, tanto la farmacocinética como la farmacodinámica para un fármaco son específicas del paciente. Un enfoque basado en la población no es idealmente adecuado para determinar los medicamentos para dolencias, tal como pacientes diabéticos donde a diario se usa un fármaco de insulina debido a la variabilidad de dicha enfermedad crónica. En dichos casos, la pauta de dosificación se ajusta normalmente por los profesionales sanitarios en ejercicio a partir de directrices dadas. Típicamente, el personal sanitario, con la ayuda del paciente, sigue una pauta de supervisión y ajuste de la dosificación de insulina controlada.

Las formas más prevalentes de diabetes se deben a la producción disminuida de insulina (diabetes mellitus de tipo 1, la primera forma reconocida) o sensibilidad disminuida de los tejidos corporales a la insulina (diabetes mellitus de tipo 2, la forma más común). El tratamiento de la primera requiere inyecciones de insulina, mientras que la segunda se controla en general con medicamentos orales y solo requiere insulina si los medicamentos orales son ineficaces. Otros problemas de salud que aceleran los efectos dañinos de la diabetes son el tabaco, niveles de colesterol elevados, obesidad, tensión arterial alta y falta de ejercicio regular. En consecuencia, el entendimiento y participación del paciente en el tratamiento son vitales, puesto que los niveles de glucosa en sangre cambian continuamente.

El control de la glucosa es el mejor procedimiento para retrasar el efecto dañino de la glucosa en los órganos. El tratamiento convencional (CT), el tratamiento convencional intensivo (ICT) y el tratamiento convencional intensivo para usuarios de bombas (CSII) son enfoques comunes usados para controlar la glucosa. Una limitación de dichos enfoques de tratamiento es que no hacen uso de herramientas que tienen en cuenta factores específicos del paciente, tales como la variabilidad fisiológica, las diferencias metabólicas y los efectos del estrés, el ejercicio, la enfermedad y las comidas.

La concentración de glucosa es el parámetro principal que se mide normalmente para el control normoglucémico (por ejemplo, para proporcionar un nivel normal de glucosa en la sangre). Otra información disponible para determinar un mejor tratamiento aborda las cargas metabólicas que resultan de diversas actividades, tales como la ingestión de comidas, la realización de actividad física, el estrés relacionado con el trabajo, etc. La administración de insulina, otros medicamentos, etc., son otros mecanismos de regulación para el parámetro fisiológico objetivo. Las reglas del tratamiento se definen en términos de mediciones de glucosa, sensibilidad a la insulina, proporción de insulina con respecto a carbohidrato, tasa de insulina basal y otros factores, tales como el nivel de estrés y el efecto del ejercicio. Excepto por las mediciones de glucosa, los enfoques actuales determinan los parámetros en base a reglas generales, reglas empíricas y evaluaciones iterativas en base a las mediciones de glucosa.

En vista de lo anterior, existe una importante deficiencia en los enfoques clínicos actuales para abordar las necesidades de un paciente diabético en la vida cotidiana. Ninguna solución única ha integrado los enfoques variables disponibles. Los procedimientos ofrecidos hasta la fecha no evalúan directamente las necesidades específicas del paciente; más bien, las características específicas se abordan durante un periodo de tiempo a través de prueba y error. Además, la simple integración de los diversos enfoques disponibles en la técnica no conseguiría el efecto deseado. Existen elementos específicos para cada uno de los procedimientos que se tienen que desarrollar y ajustar para que el procedimiento global funcione con el nivel deseado de seguridad, exactitud y solidez. Además, es deseable proporcionar a los profesionales sanitarios herramientas para obtener información específica del paciente a lo largo del tiempo y aplicar la información obtenida a modelos específicos del paciente dinámicos cuando se diseñan tratamientos para dichas enfermedades y/o enfermedades crónicas.

La presente invención comprende uno o más de los rasgos característicos enumeradas en las reivindicaciones adjuntas.

En otro modo de realización, se divulga un procedimiento computarizado para evaluar los efectos farmacocinéticos y la eficacia del tratamiento en un paciente específico en un ordenador. El procedimiento comprende: proporcionar datos del paciente al ordenador, los datos del paciente incluyen información metabólica, fisiológica y sobre el estilo de vida del paciente; realizar una comprobación de validez de los datos del paciente en el ordenador para proporcionar datos validados; analizar los datos validados en el ordenador usando uno o más modelos de paciente para cuantificar el curso de la enfermedad, para determinar el tratamiento adaptado al paciente considerando la información metabólica, fisiológica y sobre el estilo de vida, y para determinar el pronóstico del tratamiento; y proporcionar el tratamiento adaptado y el pronóstico del tratamiento.

Todavía en otro modo de realización, se divulga un sistema computarizado para proporcionar el diagnóstico, tratamiento y pronóstico médicos de un paciente con una enfermedad crónica. El sistema comprende: una obtención de datos de protocolos de obtención y modelos de paciente; un primer módulo de programa informático para someter a prueba la integridad y exactitud de los datos obtenidos según uno de los protocolos de obtención; un segundo módulo de programa informático para analizar los datos obtenidos con al menos uno de los modelos de paciente para caracterizar las necesidades metabólicas específicas del paciente; y un tercer módulo de programa informático que usa las necesidades metabólicas específicas caracterizadas del paciente en el diagnóstico del paciente para determinar un tratamiento específico del paciente y ofrecer el pronóstico del tratamiento específico del paciente.

La siguiente descripción detallada de los modos de realización de la presente invención se puede entender mejor cuando se lee junto con los siguientes dibujos, donde una estructura similar se indica con números de referencia similares, y en los que:

la FIG. 1 es un diagrama de bloques de diversas herramientas de utilidad/dispositivos para el control de la diabetes usados para capturar la actividad del paciente y asistir en el tratamiento con insulina que pueden comunicar información;

la FIG. 2 es un diagrama de bloques que ilustra un modo de realización de un sistema para el diagnóstico, tratamiento y pronóstico (DTPS) para desarrollar tratamientos específicos del paciente en base al modelado dinámico de la fisiología del paciente de acuerdo con la presente invención;

la FIG. 3 es un diagrama de bloques de un modo de realización de un programa informático usado en el sistema de la FIG. 2 y que muestra una porción de módulos funcionales de acuerdo con la presente invención;

la FIG. 4 es un diagrama de flujo de un modo de realización ilustrativo de un procedimiento para desarrollar tratamientos específicos del paciente de acuerdo con la presente invención;

la FIG. 5 es un diagrama de bloques de componentes de programa informático usados en el sistema de la FIG. 2 para proporcionar un sistema para páncreas automático (APS) para desarrollar tratamientos específicos del paciente de acuerdo con un modo de realización de la presente invención;

la FIG. 6 es un diagrama de bloques de componentes de programa informático, dispositivos e interacciones usados en el sistema de la FIG. 2 y para habilitar el programa informático de la FIG. 5 como un sistema de bucle cerrado que usa mediciones de glucosa para proporcionar una acción de control apropiada en base a un tratamiento específico del paciente de acuerdo con un modo de realización de la presente invención;

la FIG. 7 es un diagrama de bloques de componentes de programa informático, dispositivos e interacciones usados en el sistema de la FIG. 2 y para habilitar el programa informático de la FIG. 5 como un sistema de bucle abierto para proporcionar una acción de control apropiada en base a un tratamiento específico del paciente de acuerdo con un modo de realización de la presente invención;

las FIGS. 8 y 9 son diagramas de flujo del procedimiento que muestran una secuencia de ejecuciones de módulos de acuerdo con un modo de realización de un algoritmo empírico de la presente invención;

la FIG. 10 es un gráfico que muestra una relación de puntos fijos entre insulina y glucosa en diferentes momentos del día;

las FIGS. 11 y 12 son representaciones que muestran gráficamente una selección de un intervalo de tiempo para las primera y segunda funciones de procesamiento, respectivamente, de acuerdo con la presente invención;

la FIG. 13 es un par de gráficos que muestran diferentes situaciones con zonas de glucosa;

la FIG. 14 es un gráfico que muestra una subida de glucosa para una ingesta de carbohidratos de acción rápida; la FIG. 15 es un gráfico que muestra la respuesta de la glucosa en sangre a una subida de carbohidratos de acción rápida a lo largo del tiempo;

la FIG. 16 es una representación de un procesamiento de un módulo de rectificación de carbohidratos de acuerdo con la presente invención;

la FIG. 17 es un gráfico que muestra la farmacodinámica de la insulina restante;

la FIG. 18 es un gráfico que muestra los cambios en la insulina para una inyección intravenosa rápida unitaria a lo largo del tiempo;

la FIG. 19 es un gráfico que muestra una predicción de impulso de insulina;

la FIG. 20 es un gráfico que muestra las descripciones de tiempo usadas por un algoritmo de acuerdo con la presente invención;

la FIG. 21 es un gráfico proporcionado como ejemplo para ilustrar la identificación de parámetros del modelo de acuerdo con la presente invención;

la FIG. 22 es una representación de una interfaz gráfica de usuario para un programa informático paquete de pruebas con algoritmo de control para páncreas automatizado (APCATS) de acuerdo con la presente invención e implementado en el sistema de la FIG. 2 para desarrollar tratamientos específicos del paciente;

la FIG. 23 es un diagrama de bloques que muestra las conexiones entre los bloques de módulos del programa informático APCATS y el flujo de información entre los bloques; de acuerdo con la presente invención;

la FIG. 24 es una representación de una interfaz gráfica de usuario que proporciona una ventana de menú de planta usada para cambiar los parámetros del modelo de paciente para un entorno de simulación de acuerdo con la presente invención;

la FIG. 25 es una representación de una interfaz gráfica de usuario que proporciona una ventana de menú de fallos para un entorno de simulación de acuerdo con la presente invención;

la FIG. 26 es una representación de una interfaz gráfica de usuario que proporciona un formulario para la entrada de acontecimientos para un entorno de simulación de acuerdo con la presente invención;

la FIG. 27 es una representación de una interfaz gráfica de usuario que proporciona un formulario para seleccionar dieta/ejercicio acumulativo para un entorno de simulación de acuerdo con la presente invención;

la FIG. 28 es una representación de una interfaz gráfica de usuario que proporciona un formulario para los puertos de conexión para un entorno de simulación de acuerdo con la presente invención;

la FIG. 29 es una representación de una porción del panel ejecutar/almacenar de la interfaz gráfica de usuario de la FIG. 22 que proporciona la funcionalidad básica para cargar datos, guardar datos y ejecutar la simulación;

la FIG. 30 es una representación de una interfaz gráfica de usuario que proporciona un formulario para parámetros de simulación para un entorno de simulación de acuerdo con la presente invención, que permite al usuario fijar los tiempos de inicio y detención para una simulación, seleccionar una rutina de integración y un tamaño de paso, y ejecutar la simulación;

la FIG. 31 es una representación de una porción del panel de gráficas de la interfaz gráfica de usuario de la FIG. 22 que permite a un usuario mostrar en gráficos los datos experimentales en una pantalla o como una copia en papel; la FIG. 32 es una representación de una interfaz gráfica de usuario que proporciona un formulario para la entrada de inicio para un entorno de simulación de acuerdo con la presente invención;

la FIG. 33 es un flujo del procedimiento que muestra una secuencia ejecutada de componentes de programa informático de acuerdo con un modo de realización de la presente invención;

la FIG. 34 es un gráfico que muestra un periodo de control de acuerdo con un modo de realización de la presente invención; y

la FIG. 35 representa una actualización de variables con respecto a la llamada del algoritmo de acuerdo con un modo de realización de la presente invención.

En general, la presente invención es una arquitectura y procedimientos informáticos que ayudan a analizar el tratamiento y control de enfermedades, tales como diabetes, asma y cardiopatía, que son de naturaleza crónica, analizando la fisiología humana y actividad metabólica de un individuo en un sistema dinámico, y posibilitando que un usuario defina el protocolo, analice los datos obtenidos, ajuste los requerimientos del tratamiento y proporcione el diagnóstico, los consejos sobre el tratamiento y el pronóstico específicos del paciente. Aunque la presente invención en el presente documento se analiza en términos de ayudar a un paciente, se entiende que la presente invención se puede usar para ayudar a múltiples pacientes.

En un modo de realización, la presente invención potencia el resultado del tratamiento sometiendo a prueba una solución propuesta y proporcionando un intervalo de confianza en relación con él. En algunos casos, la solución propuesta es un protocolo especializado para abordar específicamente la caracterización y/o el control de un efecto, o, en algunos casos, múltiples efectos. En lugar de resolver el problema usando reglas basadas en la población, el procedimiento de la presente invención, desde el inicio, asume un estado de enfermedad específico del paciente mediante el cual adapta el tratamiento a las consideraciones metabólicas, fisiológicas y sobre el estilo de vida del paciente.

En un modo de realización, la presente invención proporciona una herramienta sistemática que aborda directamente la necesidad de determinar el tratamiento con insulina específico del paciente. Se ha de apreciar que el procedimiento de la presente invención es aplicable a sistemas de bucle abierto, de bucle cerrado y de bucle semicerrado, y se puede adaptar a diversos procedimientos de medición de glucosa y diversos procedimientos de administración de insulina. En otros modos de realización, la presente invención es aplicable a otras dolencias crónicas que requieren el tratamiento con fármacos continuo.

La presente invención usa modelos fisiológicos, modelos metabólicos y matemáticas para determinar una dosis de fármaco en base a la farmacocinética y farmacodinámica del fármaco y parámetros pertinentes. Los expertos en la técnica entienden que la farmacocinética es el estudio de la absorción, distribución, metabolismo y excreción de fármacos, mientras que la farmacodinámica es el estudio de los efectos bioquímicos y fisiológicos de los fármacos y sus mecanismos de acción, y de la correlación de las concentraciones del fármaco con respecto a los efectos del fármaco. En un modo de realización, la presente invención computariza la metodología de la farmacodinámica para operar sobre datos introducidos y proporciona como resultado la relación entre la farmacocinética y el efecto farmacológico como adverso o bien deseado.

La presente invención ayuda a los usuarios a entender los efectos farmacológicos de diversos estados fisiológicos y ayuda a diagnosticar la enfermedad, a perfeccionar el tratamiento y permite el desarrollo no solo de un tratamiento que sea específico del paciente, sino de un tratamiento que sea más riguroso que los tratamiento existentes. El sistema y los procedimientos del mismo de la presente invención se amplían además para proporcionar el pronóstico para la enfermedad crónica del individuo.

En un modo de realización, la invención divulga un aparato desde la perspectiva de entradas con introducción de datos genéricas y/o entradas con salida de datos genéricas para dispositivos de (i) recepción/solicitud, (ii) algoritmo y (iii) informar al usuario de advertencias informativas/de utilidad clínica de los resultados. La información sobre acontecimientos puede ser una actualización continua o producirse de manera discreta. Un acontecimiento es, por tanto, una transacción. El procedimiento describe además la estructura del algoritmo para posibilitar la generación del tratamiento.

En otro modo de realización, la invención divulga un procedimiento que usa los datos sobre glucosa obtenidos y otra información disponible para sintetizar el modelo específico del paciente y usarlo para determinar los parámetros del tratamiento. Este procedimiento puede implicar (1) identificar un modelo específico del paciente y (2) definir los diversos parámetros fisiológicos. Se simula el modelo identificado o se aplican herramientas de análisis específicas para cumplir con la definición de los parámetros fisiológicos para deducir sus valores. Los parámetros determinados son específicos del paciente, puesto que derivan de un modelo específico del paciente.

En otro modo de realización, la presente invención posibilita además que un usuario realice diversos análisis, incluyendo la evaluación de situaciones críticas por medio de simulaciones, para garantizar una solución estable y sólida que cumpla con requerimientos tales como las directrices de la ADA y/o mantiene a los parámetros clave, por ejemplo, HbA1C, en un intervalo objetivo deseado del sujeto.

La presente invención posibilita, por tanto, que un médico en ejercicio con una herramienta que ayuda a analizar el comportamiento característico del paciente y que, a su vez, usa este análisis para determinar el tratamiento, examine los resultados del tratamiento y entienda las características del paciente. La presente invención es un sistema integrado que alberga los diversos componentes del sistema —almacenamiento de datos del paciente, herramientas de análisis matemático, procedimientos de presentación de datos, integración con dispositivos externos, técnicas de cumplimiento de los datos, enfoques de tratamiento sometidos a prueba en cuanto a su estabilidad y solidez— que, en conjunto, ofrecen un enfoque superior para el diagnóstico, determinación del tratamiento y pronóstico para pacientes con diabetes. En lo sucesivo, y usando la diabetes como ejemplo, la presente invención se elabora con mayor detalle. En particular, ahora se proporciona un análisis sobre las mediciones, análisis y otra información usada por la presente invención.

Mediciones y análisis

Como se sabe, la diabetes es un síndrome metabólico en el que la fisiología del cuerpo no funciona normalmente para regular la glucosa en sangre por diversos motivos causales. Para controlar la enfermedad, existen muchas introducciones de datos, herramientas de utilidad y dispositivos para el control de la diabetes usados para capturar la actividad del paciente y asistir en el tratamiento con insulina. Por ejemplo, la FIG. 1 es una ilustración de los componentes de control de enfermedades típicos para controlar la diabetes que necesitan interactuar e intercambiar información para determinar y evaluar la eficacia del tratamiento con insulina recetado. Los componentes de control de enfermedades incluyen: ordenadores personales, bases de datos centralizadas para la gestión de datos, algoritmos que proporcionan procedimientos para controlar la infusión por bomba en base a las introducciones de datos por el usuario, mediciones de glucosa y cantidades administradas de insulina, introducciones de datos por el usuario por medio de la interfaz de usuario, mediciones, pruebas, etc., introducciones de datos por el profesional sanitario (PS) por medio de la interfaz de usuario, mediciones, pruebas; y bombas de insulina inteligentes, medidores de glucosa en sangre (bG) inteligentes y otros dispositivos de mano que pueden ser dispositivos integrados o bien autónomos que funcionan de forma independiente. En general, estos componentes de control de enfermedades interactúan para intercambiar información entre sí, lo que se muestra por medio de las flechas en la FIG. 1. Dicho intercambio de información (datos) es un requerimiento regular cuando se realizan llamadas de función por programas asociados con/proporcionados por los componentes y, en general, se llaman junto con argumentos de introducción de datos/salida de datos. Los argumentos representan el contenido estructurado y, al menos todos los componentes de control de enfermedades del dispositivo deberían entender idealmente dicha estructura y su contenido potencial/real. Sin embargo, en dicho sistema, informar a diversos componentes de que se ha producido un acontecimiento es un problema. Un acontecimiento es una unidad de información generada por un componente que se puede usar por otro componente (por ejemplo, una medición de bG, episodio hipoglucémico, valor de episodio hiperglucémico, ajuste de una dosificación, cambio de un protocolo, cambio de un algoritmo, etc.). En particular, el problema radica en proporcionar una estructura de información que capture la información necesaria de un amplio conjunto de casos de uso que usan dichos componentes de control de enfermedades. Los problemas adicionales radican en el hecho de que el intercambio de información cuando se controla una enfermedad crónica, tal como la diabetes, es crítico en el tiempo, así como crítico para el contenido. Además, la información intercambiada se tiene que poder usar por los dispositivos para la interpretación por la máquina, así como por los seres humanos para la interpretación humana.

La característica de la información de intercambio también es otro problema. Por ejemplo, las características de la información en el control de una enfermedad crónica se anotaron como sigue. El tiempo tiene muchas variaciones, por ejemplo, cuándo ocurre el acontecimiento, cuándo se produce un acontecimiento con respecto a otro acontecimiento y durante cuánto tiempo se puede producir el acontecimiento. Un acontecimiento por sí mismo tiene una naturaleza característica y se necesitan los siguientes aspectos: qué acontecimiento se desencadena, cuál es la intensidad o magnitud del acontecimiento. Un acontecimiento podría consistir en una ocurrencia en el tiempo especificado o serie de ocurrencias con la magnitud correspondiente de la acción especificada. ¿Se puede desactivar un acontecimiento una vez que se haya iniciado? O una pregunta más general es ¿se puede modificar el acontecimiento previo siendo un caso específico la eliminación? La frecuencia del acontecimiento también se necesita conocer. ¿Cómo se desencadena el acontecimiento en el contexto de ser una llamada síncrona o bien una llamada asíncrona? La presente invención aborda estos problemas como será evidente en el análisis proporcionado en lo sucesivo.

Las mediciones de los parámetros fisiológicos forman la base del DTPS. Por ejemplo, existen parámetros fácilmente mensurables, tales como la temperatura corporal, tensión arterial, peso corporal, etc. Se pueden proporcionar otros parámetros a partir de pruebas de laboratorio elaboradas, tales como pruebas sobre muestras de sangre usadas para identificar constituyentes específicos, análisis de orina y cultivos realizados para identificar microbios, etc. Sin embargo, existen limitaciones a la medición de cualquier parámetro fisiológico. Por ejemplo, una configuración compleja y costosa puede limitar la disponibilidad de la información proporcionada, tal como, por ejemplo, de pruebas similares a la HbA1C o ensayos de insulina. Se puede distorsionar la información cuantitativa y/o cualitativa sobre las actividades que provocan un impacto sobre la fisiología humana, tales como el ejercicio, la ingesta de comidas (es decir, la ingestión de carbohidratos) y el estrés. Además, estos parámetros pueden aparecer como efectos que se designan como activados/desactivados en lugar de cuantificarse. Además, se espera que la información cuantificada no se pueda conseguir de forma concreta para diversos factores limitantes. También existen limitaciones tecnológicas, por ejemplo, mediciones no disponibles debido a limitaciones físicas o éticas para acceder a un parámetro fisiológico, tales como la cantidad de gluconeogénesis o la absorción de glucosa intestinal, por ejemplo. Además, los parámetros construidos matemáticamente, tales como la biodisponibilidad y la eficacia de los fármacos, se basan normalmente en la población y pueden no ser lo suficientemente específicos para determinados pacientes individuales.

Para el tratamiento de la diabetes, las mediciones de glucosa obtenidas normalmente usando medidores de glucosa son los parámetros principales para llevar a cabo el control del tratamiento. Existen varios parámetros secundarios pertinentes para controlar la diabetes, tales como la HbA1C, las cetonas y los AGL. Sin embargo, dichas mediciones no se necesitan de forma regular. Además, existe información sobre las actividades (tales como las tasas de cantidad y ejecución para el consumo de comida y el ejercicio) que es importante para ajustar y corregir el tratamiento. La presente invención, que puede ayudar a analizar las necesidades específicas del paciente, emplea dichos datos en mediciones y análisis para generar modelos que se usan para estimar parámetros fisiológicos que no se pueden medir directamente y para representar la fisiología y metabolismo subyacentes del paciente. La presente también permite la visualización de dichos parámetros fisiológicos a medida que evolucionan continuamente, de tal manera que el usuario pueda entender el comportamiento dinámico subyacente de la enfermedad crónica. Dichos análisis y visualización de la presente invención ofrecen un mayor entendimiento sobre el funcionamiento del sistema (la persona diabética) y pueden ayudar al personal sanitario con el diagnóstico, determinación del tratamiento y pronóstico. En consecuencia, la presente invención potencia la capacidad del personal sanitario para analizar datos, diagnosticar la enfermedad, determinar el tratamiento y llegar a un pronóstico para el tratamiento. Para ayudar a ilustrar la utilidad de la presente invención, en lo sucesivo se proporciona el siguiente ejemplo.

Para detectar la diabetes en un individuo, un protocolo usado comúnmente requiere que el individuo ayune durante al menos 8 horas. Se mide la glucosa en ayunas y, entonces, el individuo se somete a una prueba de tolerancia a la glucosa oral, que supone la ingesta de una bebida de glucosa concentrada, seguido de varias mediciones de glucosa normalmente durante el transcurso de 2 horas. En base a los datos obtenidos, se determina un diagnóstico para la diabetes. El uso de datos frecuentes o continuos ofrece las siguientes ventajas sobre el uso de mediciones dispersas: los datos se pueden mostrar en gráficas para visualizar patrones y tendencias; los datos se pueden usar para predecir o anticipar cambios de las mediciones; y los datos se pueden usar para generar modelos y representar la farmacocinética y farmacodinámica subyacentes. En general, los datos mencionados anteriormente se obtienen usando protocolos bien definidos. El procedimiento de la presente invención engloba los siguientes aspectos. Se obtienen datos específicos del paciente para respaldar las herramientas de diagnóstico, tratamiento y pronóstico de la presente invención. Se propone un análisis de los datos reconociendo qué protocolos son específicos del análisis y que cada protocolo está especializado para identificar o determinar un aspecto particular de la enfermedad (una relación causa-efecto). El análisis de los datos propuesto pretende cuantificar mejor cómo funciona el sistema de enfermedad del paciente e identificar los parámetros específicos del paciente. Luego, el comportamiento dinámico del sistema de enfermedad del paciente se define por la presente invención, reconociendo que los estudios basados en la población representan efectos promedio y no abordan necesariamente las necesidades específicas del paciente. La presente invención también tiene en cuenta que, aunque los principios necesarios para entender cómo se comporta un sistema dinámico pueden quedar claros en una situación específica, no es razonable esperar que una persona realice mentalmente un análisis matemático crítico.

Por ejemplo, los medicamentos, especialmente los que se usan diariamente y/o se necesitan de forma regular, interactúan con actividades tales como el ejercicio, el estrés, diferentes alimentos y otros medicamentos, todos los cuales pueden tener una influencia sustancial sobre el efecto de los medicamentos. Una herramienta sistemática de la presente invención descrita en lo sucesivo en una sección posterior que desarrolla los aspectos matemáticos de la determinación de dichos efectos ayudará al personal sanitario a evaluar y cuantificar el efecto. Los efectos se pueden traducir además en la pauta del medicamento para un efecto dado para el que se selecciona el tratamiento correspondiente. Los efectos se pueden usar para predecir el impacto del efecto y para ayudar a generar advertencias y alertas. La descripción en lo sucesivo explica el sistema (aparato) y la metodología de la presente invención.

Sistema global

Con las mediciones y análisis anteriores en mente, el DTPS es un sistema equipo físico-programa informático que opera en un entorno cliente-servidor típico que se ejecuta en una plataforma de PC, y se ilustra en el diagrama de bloques mediante la FIG. 2. El sistema global se considera distribuido geográficamente y accesible por medio de una configuración de intranet y/o internet. En un modo de realización ilustrado, el sistema 10 proporciona un ordenador servidor 12 y un ordenador cliente 14. El ordenador servidor 12 incluye un procesador 16 convencional que se conecta funcionalmente a un dispositivo de introducción de datos 18, un monitor 20 y una memoria 22 (por ejemplo, RAM, ROM y unidad(es) de disco duro). El dispositivo de introducción de datos 18 puede ser uno cualquiera o una combinación de un teclado convencional, un dispositivo para apuntar y hacer clic convencional, un micrófono o similar, y el monitor 20 puede ser cualquier monitor de ordenador convencional. El procesador 16 del ordenador servidor 12 también se conecta funcionalmente a una base de datos 24, es interno al ordenador 12 o, de forma alternativa, puede ser externo al ordenador 12. El procesador 16 del ordenador servidor 12 se conecta funcionalmente además a una interfaz de comunicación 26 convencional.

Igualmente, el ordenador cliente 14 incluye un procesador 34 convencional que se conecta funcionalmente a un monitor 36 convencional, memoria 38 convencional (por ejemplo, RAM, ROM y unidad(es) de disco duro) y un dispositivo de introducción de datos 40 convencional que puede ser uno cualquiera o una combinación de un teclado convencional, un dispositivo para apuntar y hacer clic convencional, micrófono o similar. De forma alternativa, la introducción de datos también puede ser por medio del monitor 36 en modos de realización en los que el monitor 36 incluye uno o más botones o conmutadores de pantalla táctil. El ordenador cliente 14 puede incluir además uno o más altavoces 42 convencionales conectados funcionalmente al procesador 34. El procesador 34 del ordenador cliente 14 se conecta funcionalmente además a una interfaz del dispositivo 46 que se configura para conectarse funcionalmente, sin cables o bien por medio de una conexión por cable, a uno o más dispositivos externos.

En un modo de realización, por ejemplo, la interfaz del dispositivo 46 puede ser o incluir un puerto de entrada/salida convencional configurado para conexión por cable a un dispositivo externo.

Los ejemplos de dicho puerto de entrada/salida convencional incluyen, pero no deberían estar limitados a, un puerto de bus serie universal (USB) convencional, un puerto RS-232 convencional o similares. De forma alternativa o adicionalmente, la interfaz del dispositivo 46 puede ser o incluir un transmisor receptor sin cables convencional configurado para comunicarse sin cables con un transmisor receptor similar de un dispositivo externo. Los ejemplos de dicho transmisor receptor sin cables incluyen, pero no deberían estar limitados a, un transmisor receptor de infrarrojos (IR), un transmisor receptor de radiofrecuencia (RF), un transmisor receptor inductivo, un transmisor receptor acústico o similares.

El procesador 34 del ordenador cliente 14 proporciona información a, o recibe información de, un dispositivo externo 48, tal como en forma de un dispositivo de medición y/u obtención de datos del paciente, por medio de la interfaz del dispositivo 46. Los ejemplos del dispositivo de medición y/u obtención de datos del paciente 48 pueden incluir, pero no deberían estar limitados a, un sensor de glucosa en sangre o tejido u otro dispositivo de medición de glucosa, un dispositivo de medición o detección de la temperatura corporal, un dispositivo de medición del peso corporal, un dispositivo de monitorización de la tensión arterial, un dispositivo de monitorización de la HbA1C, una bomba de infusión de fármacos implantable o de uso externo, por ejemplo, para la administración de insulina o de uno o más fármacos para reducir o aumentar la glucosa en sangre, un dispositivo de mano u otro dispositivo de obtención de datos para monitorizar los datos sobre la ingesta de comidas del paciente, datos sobre el ejercicio del paciente, datos sobre la enfermedad del paciente, etc., o similares.

El procesador 34 del ordenador cliente 14 se conecta funcionalmente además a una interfaz de comunicación 32 convencional. Las interfaces de comunicación 26 y 32 pueden ser cualquier interfaz de comunicación convencional que proporcione comunicaciones electrónicas entre el ordenador servidor 12 y el ordenador cliente 14. En el modo de realización ilustrado, por ejemplo, las interfaces de comunicación 26 y 32 se configuran para proporcionar comunicaciones electrónicas entre el ordenador servidor 12 y el ordenador cliente 32 por medio de la red informática mundial (WWW), internet y/o intranet de manera convencional. De forma alternativa o adicionalmente, las interfaces de comunicación 26 y 32 pueden ser o incluir módems telefónicos de modo que el ordenador servidor 12 y el ordenador cliente 32 se puedan comunicarse por medio del teléfono. La presente divulgación contempla que se pueden conseguir de forma alternativa las comunicaciones electrónicas entre el ordenador servidor 12 y el ordenador cliente 14 por medio de otros enlaces de comunicaciones por cable o sin cables convencionales. En cualquier caso, se entenderá que el sistema 10 puede incluir múltiples ordenadores servidor en red 12 que se pueden distribuir geográficamente o no, y que cada ordenador servidor 12 puede dar servicio a múltiples ordenadores cliente 14 que se pueden distribuir geográficamente. Además, los procedimientos (es decir, la porción de programa informático) de la presente se pueden configurar en el lado del cliente o en el lado del servidor, dependiendo de la situación de los casos de uso, que se analiza en lo sucesivo.

Porciones de programa informático

Con referencia a la FIG. 3, se muestra un modo de realización ilustrativo del programa informático 50 usado por el sistema 10 de la FIG. 2 y de acuerdo con la presente invención. Se entenderá que el programa informático 50 se configura de manera convencional para permitir la interacción apropiada entre el ordenador cliente 14 y el ordenador servidor 12 para realizar la autenticación del usuario, adquirir y/o almacenar datos en una base de datos y llevar a cabo actividades auxiliares, tales como el procesamiento subordinado de datos, automatización de acontecimientos desencadenantes, y similares. En el modo de realización ilustrado, el programa informático 50 incluye un sistema operativo y una porción de protocolo de red 52, una porción de aplicaciones de núcleo 54 y una porción de módulos funcionales 56. El sistema operativo y la porción de protocolo de red 52 se configuran de manera convencional para permitir la interacción entre los diversos ordenadores, dispositivos y/o bases de datos. Las porciones de aplicaciones de núcleo y de módulos funcionales 54 y 56, respectivamente, pueden residir en el ordenador servidor 12, el ordenador cliente 14, o al menos en parte en ambos.

En general, la porción de aplicaciones de núcleo 54 comprende una serie de algoritmos de programa informático convencionales y otro programa informático de gestión de datos convencional, que pueden estar disponibles comercialmente. Como un ejemplo específico, la porción de aplicaciones de núcleo 54 puede contener paquetes de programa informático matemáticos convencionales. En general, dichas herramientas matemáticas principales incluirán una o más herramientas de optimización, una o más herramientas de análisis estadístico, una o más herramientas de simulación, una o más herramientas de sensibilidad, una o más herramientas de visualización y una o más herramientas para extraer información (tales como herramientas de reconocimiento de patrones convencionales, herramientas de reconocimiento envolventes, y similares). Los ejemplos específicos incluyen, pero no están limitados a, uno cualquiera o más de LAPACK, un paquete de álgebra lineal, herramientas y bibliotecas de programa informático de IMSL (Independent Media Solutions Limited), herramientas cliente/servidor de OPTIMA, herramientas estadísticas de STATS, herramientas de presentación gráfica, y similares. Los algoritmos de organización de bases de datos y de programa informático de seguridad, en particular, para los datos del paciente obtenidos, son otros ejemplos específicos de algoritmos de programa informático convencionales y otro programa informático de gestión de datos convencional que pueden estar contenidos en la porción de aplicaciones de núcleo 54. Dichos algoritmos de organización de bases de datos y de programa informático de seguridad garantizarán, en general, por ejemplo, el cumplimiento de la HIPAA, la integridad, seguridad, autenticación de los datos, y la interoperabilidad con otras aplicaciones del sistema. Los controladores convencionales para admitir diversas actividades de la base de datos y/o controladores para interactuar con diversos dispositivos de medición/obtención de datos electrónicos 48 (véase la FIG. 2) son otro ejemplo específico de algoritmos de programa informático convencionales y otro programa informático de gestión de datos convencional que pueden estar contenidos en la porción de aplicaciones de núcleo 54, así como uno o más navegadores web convencionales para permitir la interacción con diversos ordenadores, bases de datos y sitios web apropiados. Los ejemplos de dichos navegadores web convencionales pueden incluir, pero no deberían estar limitados a, Internet Explorer, Netscape, Mozilla, Opera, Lynx, y similares. Se entenderá que la porción de aplicaciones de núcleo 54 puede incluir más o menos algoritmos de programa informático y/o programa informático de gestión de datos, y que los ejemplos anteriores se han proporcionado solo para propósitos ilustrativos y de ninguna forma se deben considerar limitantes.

Módulos funcionales

Como se muestra mediante la FIG. 3, en el modo de realización ilustrado, la porción de módulos funcionales 56 incluye un bloque de protocolos de obtención de datos 70, un módulo de modelos de paciente 72, un módulo de validación del modelo 74 y un módulo de análisis 76, todos conectados a un módulo de conjunto de reglas/directrices 78. La porción de módulos funcionales 56 incluye además un módulo de control de controladores del dispositivo y un módulo de validación y presentación de los resultados 82. De forma ilustrativa, la porción de módulos funcionales 56 funciona para gestionar datos, consultar datos, almacenar y recuperar datos, proporcionar rutinas de llamadas con respecto a paquetes matemáticos y bibliotecas localizados en la porción de aplicaciones de núcleo 54, proporcionar rutinas para analizar datos y rutinas gráficas para presentar datos en forma de texto y gráficos, y proporciona controladores para comunicarse con diversos dispositivos externos 48. De forma alternativa o adicionalmente, la porción de módulos funcionales 56 se puede configurar para realizar más o menos funciones.

Para desarrollar un tratamiento específico del paciente para una enfermedad en general, y para una enfermedad crónica específicamente, se obtienen datos relacionados específicamente con el paciente. En general, el tipo de datos específicos del paciente que se han de obtener y la manera en que se han de obtener dependen de muchos factores, incluyendo, pero no limitados a, la enfermedad particular para la que se desarrolla el tratamiento, la gravedad de la enfermedad, los tipos y disponibilidad de las soluciones de tratamiento, la edad, peso y sexo del paciente, uno o más de los hábitos personales del paciente, tales como la propensión del paciente a seguir un régimen alimenticio estricto y/o realizar ejercicio de forma regular, para seguir una o más programaciones de tratamiento disponibles, y similares. El módulo de protocolos de obtención de datos 70 contiene múltiples protocolos de obtención de datos diferentes, cada uno diseñado para proporcionar la obtención de uno o más tipos particulares de datos específicos del paciente que se han de obtener de manera particular. Más específicamente, cada protocolo de obtención de datos contenido en el módulo de protocolos de obtención de datos 70 especifica los datos que se han de obtener, la manera en que los datos se han de obtener, es decir, la manera en que se ha de realizar la obtención de datos, cualquier restricción en el protocolo de obtención de datos, cualquier herramienta y/o dispositivo especial, electrónico o de otro modo, que se ha de usar en la obtención de datos, y cualquier técnica de protección y/u obtención de datos que garantice y/o incremente la calidad de los datos obtenidos. De forma ilustrativa, los datos específicos del paciente que se obtienen de acuerdo con cualquiera de los diversos protocolos de obtención de datos se almacenan en la base de datos 24 (FIG. 2), aunque algunos o todos estos datos obtenidos se pueden almacenar de forma alternativa en una o más de otras bases de datos y/o unidades de memoria que es/son accesible(s) por el ordenador servidor 12 y/u ordenador cliente 14.

Cada protocolo de obtención de datos almacenado en el módulo de protocolos de obtención de datos 70 se define para un propósito específico y comprende un esquema de obtención de datos que se ha sometido a prueba y evaluado para lograr al menos un objeto particular, siempre que se hayan satisfecho las comprobaciones sobre el cumplimiento e integridad de los datos convencionales. Para este fin, cada protocolo de obtención de datos puede incluir, o tener acceso a, por ejemplo, un procedimiento de cumplimiento de los datos en forma de un módulo matemático que comprueba las inconsistencias en los datos obtenidos, y que comprueba los requerimientos definidos para los datos particulares que se han obtenido. Los ejemplos de dichos requerimientos incluyen, pero no están limitados a, la consistencia del registro del tiempo, el/los intervalo(s) de valores de los datos, el/los intervalo(s) de fechas, y similares. Adicionalmente, cada protocolo de obtención de datos puede incluir, o tener acceso a, por ejemplo, un procedimiento de calidad de los datos en forma de un módulo matemático que examina la calidad de los datos obtenidos en términos de su rendimiento y/o propiedades estadísticas.

El módulo de conjuntos de reglas/directrices 78 proporciona conjuntos de reglas que dirigen la obtención de datos específicos del paciente de acuerdo con los diversos protocolos de obtención de datos disponibles en el módulo de protocolos de obtención de datos 70. Adicionalmente, el módulo de conjuntos de reglas/directrices 78 proporciona directrices para obtener los datos específicos del paciente de acuerdo con los diversos protocolos de obtención de datos. Dichas directrices pueden proporcionar, por ejemplo, pero no están limitadas a, descripciones legibles por ordenador de los diversos protocolos de obtención de datos, orientación sobre cuándo, es decir, bajo qué circunstancias, usar o cuando no usar un protocolo o protocolos particulares, ventajas y/o desventajas de usar un protocolo, objetivos que se pueden lograr o no lograr usando un protocolo, limitaciones de un protocolo o de la aplicabilidad de un protocolo, o similares.

En general, los datos que se obtienen para cualquiera de los diversos protocolos de obtención de datos en el módulo de protocolos de obtención de datos 70 se pueden obtener de diversas formas usando diversas técnicas convencionales. Los ejemplos incluyen, pero no están limitados a, mediciones de un estado o estados específicos del paciente usando uno o más dispositivos de medición, acontecimientos o condiciones convencionales a los que se somete un paciente, y similares. Las mediciones de los datos específicos del paciente pueden estar disponibles para el ordenador cliente 14 usando uno cualquiera o más de los dispositivos electrónicos 48 descritos en el presente documento. Adicionalmente o de forma alternativa, las mediciones de los datos específicos del paciente se pueden realizar usando dispositivos y/o sistemas de medición electrónicos o no electrónicos convencionales, y los resultados se pueden introducir manualmente en el ordenador cliente 14 usando el dispositivo de introducción de datos 40, por ejemplo, teclado, dispositivo para apuntar y hacer clic, micrófono u otro dispositivo o mecanismo de introducción de datos convencional. Los acontecimientos o condiciones a los que se somete un paciente pueden incluir, por ejemplo, pero no deberían estar limitados a, la ingesta de comidas y tentempiés, el ejercicio, la enfermedad, el estrés, y similares. Dicha información puede estar disponible para el ordenador cliente 14 por medio de uno o más dispositivos electrónicos 48 y/o por medio de entrada manual usando uno de los dispositivos de introducción de datos convencionales.

Los ejemplos de protocolos de obtención de datos que pueden estar disponibles en el módulo de protocolos de obtención de datos 70 incluyen, pero no están limitados a, uno o más protocolos de obtención de datos que proporcionan la obtención de mediciones de glucosa en sangre o tejido del paciente como una función del tiempo, de mediciones de la temperatura corporal del paciente como una función del tiempo, de las mediciones de la temperatura ambiente (alrededor del cuerpo de un paciente) como una función del tiempo, de la frecuencia cardíaca y/o frecuencia del pulso del paciente como una función del tiempo, de la tensión arterial del paciente en función del tiempo, de uno o más de otros parámetros de condición fisiológica del paciente, tales como peso, menstruación, estrés, enfermedad y similares, de comida o tentempié, es decir, ingesta de carbohidratos, información como una función del tiempo, de la actividad física del paciente en función del tiempo, de la información sobre la administración de insulina a lo largo del tiempo, de la información sobre la intervención como una función del tiempo, de las visitas del paciente a las clínicas y/u hospitales como una función del tiempo, información específica sobre uno o más de ingesta de comidas, rendimiento del ejercicio y similares, uso de instrumentos y/o dispositivos especializados, uso de una o más copias en papel, llamadas telefónicas, comunicaciones por internet para intercambiar y/o registrar información, y similares.

El sistema 10 de la FIG. 2 está diseñado de forma ilustrativa para dirigirse a la especie humana, aunque se contemplan modos de realización del sistema 10 que se dirigen a otros animales por la presente divulgación. En general, algunas de las características de comportamiento presentadas por los seres humanos son comunes en todas las especies, mientras que otras características de comportamiento individuales dependen de otros factores, tales como el género, la edad, la etnia, y similares. Se pueden construir modelos de comportamiento fisiológico humano como representaciones matemáticas de la fisiología humana, y se pueden definir de forma ilustrativa en términos de ecuaciones diferenciales. Dichos modelos de paciente se pueden desarrollar además para que en general sean los mismos en todos los pacientes mientras que también anticipan la variabilidad de comportamiento. En dichos casos, los parámetros del modelo tendrán valores específicos del paciente.

El módulo de modelos de paciente 72 (FIG. 3) pone a disposición una pluralidad de dichos modelos de paciente que se configuran para modelar matemáticamente uno o más aspectos de la fisiología humana, que proporciona el mapeo con respecto a diferentes estados, condiciones y/o parámetros fisiológicos. Por ejemplo, el módulo de modelos de paciente 72 puede modelar la absorción de glucosa en los seres humanos, mientras que uno o más de otros modelos pueden modelar uno o más efectos de la administración de insulina (u otro fármaco que aumente o reduzca la glucosa). El módulo de modelos de paciente 72 puede incluir modelos competidores que se configuran para modelar el mismo aspecto fisiológico, y cada uno de dichos modelos puede tener determinadas ventajas o desventajas para definir parámetros del modelo particulares, para obtener datos relacionados con el paciente y/o para analizar datos particulares. A este respecto, el módulo de conjuntos de reglas/directrices 78 puede incluir reglas y/o directrices en relación con la aplicabilidad o inaplicabilidad particular de un modelo sobre otro para un aspecto fisiológico particular, para un tipo de paciente particular (por ejemplo, edad, género, raza, etc.) y/o situación de uso, en relación con limitaciones en el uso de cualquier modelo en particular, en relación con enlaces a fuentes donde el trabajo de modelado puede estar en proceso de desarrollo, y similares. Uno o más de los modelos pueden incluir además información sobre el caso de uso adjunta. La pluralidad de diferentes modelos de paciente disponibles por medio del módulo de modelos de paciente 72 permite el mapeo de modelos y/o parámetros del modelo con respecto a estados, condiciones o parámetros fisiológicos específicos.

Se pueden almacenar y/o acceder a los modelos de paciente directamente por el módulo de modelos de paciente 72 desde un dispositivo de memoria portátil 44, memoria de ordenador 38 y/o un medio legible por ordenador, tal como, por ejemplo, un disco compacto, disco de video digital, y similares. Se puede acceder a y/o almacenar los modelos de paciente indirectamente por el módulo de modelos de paciente 72 desde la base de datos 24 u otras unidades de memoria conectadas al servidor 12 y/o internet 30. Por ejemplo, la base de datos 24 u otras unidades de memoria pueden incluir un banco de datos de tipos y/o estructuras de modelos con enlaces pertinentes a la literatura y/u otros documentos técnicos pertinentes. De forma alternativa o adicionalmente, la base de datos 24 u otra unidad de memoria puede incluir un banco de datos de resultados de ensayos clínicos, por ejemplo, estudios de seguimiento y/o enlaces pertinentes a la información relacionada con dichos ensayos clínicos, a partir de los que se puede obtener la estructura del modelo subyacente. En cualquier caso, a uno o más modelos de paciente adecuados se puede acceder directa o indirectamente accediendo, por medio del módulo de modelos de paciente 72, a la información relacionada con la estructura, los parámetros y/o el desarrollo de dichos uno o más modelos. En general, entonces, el módulo de modelos de paciente 72 puede contener uno o más modelos de paciente desarrollados que son específicos para uno o más aspectos particulares de la fisiología humana, y/o puede contener información a partir de la cual uno o más de dichos modelos se pueden localizar, determinar y/o desarrollar. El uno o más modelos de paciente desarrollados pueden ser o incluir uno o más modelos de paciente patentados, es decir, desarrollados por una persona y/o entidad particular y restringidos en su uso por esa persona y/o entidad, y/o uno o más modelos de paciente comercialmente o de otro modo disponibles públicamente, es decir, disponibles de una o más terceras partes.

Cuando se ha seleccionado un modelo particular usando el módulo de modelos de paciente 72, entonces, se deben determinar los valores de los parámetros del modelo. Para conseguir esto, el módulo de modelos de paciente 72 puede incluir además uno o más submódulos que proporcionan la determinación de dichos parámetros del modelo. Los ejemplos de dichos uno o más submódulos de determinación de los parámetros pueden incluir, pero no deberían estar limitados a, uno o más submódulos para identificar parámetros del modelo, uno o más submódulos para proporcionar una introducción de datos, salida de datos, estado y/o descripciones de parámetros, uno o más submódulos para determinar intervalos de parámetros, uno o más submódulos para determinar sensibilidades de los parámetros del modelo (por ejemplo, valores de ganancia de parámetros del modelo), uno o más submódulos para proporcionar parámetros del modelo previamente desarrollados, derivados o definidos, y similares.

Uno o más de los submódulos para identificar los parámetros del modelo pueden emplear técnicas de ajuste de datos que determinan implícita o explícitamente los valores de parámetro. Los ejemplos generales de dichos submódulos incluyen, pero no están limitados a, aquellos que proporcionan: el análisis bayesiano para proporcionar una averiguación inicial y proporcionar una distribución anterior para estimaciones de parámetros, una función de coste para solucionar estimaciones de parámetros (distribución posterior), análisis estadístico, análisis numérico, técnicas iterativas/no iterativas para el análisis de intervalos, análisis de valores de ganancia, análisis de situaciones de prueba, modelado y aquellos que proporcionan descripciones (introducción de datos, salida de datos, estado, etc.), intervalos y sensibilidades (por ejemplo, valores de ganancia) de parámetros conocidos previamente. De forma alternativa o adicionalmente, uno o más de los submódulos para identificar parámetros del modelo pueden especificar un procedimiento o marco para identificar los parámetros del modelo. Un ejemplo de uno de dichos procedimientos o marcos de identificación de parámetros del modelo, que de ninguna forma se debe considerar limitante, es uno que: i) proporciona los parámetros del modelo y las averiguaciones iniciales para los parámetros, ii) si se sigue un enfoque bayesiano, proporciona una base para la estimación de parámetros, iii) configura, selecciona o usa una función de coste particular, iv) selecciona o usa una técnica o marco de solución de funciones de coste particular, y v) soluciona de forma iterativa o no iterativa las estimaciones de parámetros del modelo.

Uno o más de los submódulos para determinar los intervalos de parámetros pueden emplear una cualquiera o más de las técnicas estadísticas, numéricas, iterativas o no iterativas para determinar implícita o explícitamente los intervalos aceptables para uno o más de los parámetros del modelo y/o para determinar la variabilidad de los parámetros del modelo. Uno o más de dichos submódulos, por ejemplo, pueden usar técnicas convencionales para crear situaciones de prueba que representan intervalos de parámetros del modelo en los que se puede someter a prueba y evaluar el modelo. Por ejemplo, en un modo de realización la presente invención se puede usar para definir e implementar situaciones de prueba en el ordenador que ayudan a someter a prueba el tratamiento específico del paciente recomendado y cuantificar la calidad del tratamiento que se puede lograr potencialmente usando el tratamiento específico del paciente recomendado. En otros modos de realización, cuando se especifica el tratamiento, la presente invención se puede usar para evaluar la situación y aumentar el tratamiento, tal como por ejemplo, con limitaciones sobre el estilo de vida, por ejemplo, límites de la cantidad de comida, restringir las comidas de absorción rápida, y similares.

Uno o más de los submodelos para determinar las sensibilidades de los parámetros del modelo pueden emplear una o más técnicas estadísticas, numéricas, iterativas o no iterativas para determinar implícita o explícitamente los valores de ganancia de parámetros del modelo. Uno o más de dichos submódulos pueden usar, por ejemplo, técnicas convencionales para analizar las sensibilidades de los parámetros del modelo para evaluar la estabilidad del modelo en uno o más intervalos de parámetros del modelo y/o en respuesta a errores en la determinación de los parámetros del modelo.

Para el tratamiento de la diabetes en particular, las mediciones de glucosa obtenidas usando diversas técnicas de medición de glucosa en sangre y/o tejido conocidas proporcionan un parámetro principal alrededor del que se busca lograr el control normoglucémico por medio del tratamiento de la diabetes convencional. La presente divulgación reconoce que también son pertinentes otros parámetros para controlar la diabetes, y que la determinación dinámica o estática de dichos parámetros puede que se necesite o no de forma regular o periódica. Los ejemplos de dichos otros parámetros incluyen, pero no están limitados a, HbA1C (hemoglobina glucosilada o glucohemoglobina —una forma de hemoglobina que se puede usar para identificar la concentración de glucosa en plasma a lo largo del tiempo —), AGL (ácidos grasos libres), cuerpos cetónicos (subproductos de la descomposición de los ácidos grasos), y similares. Mientras que algunos de dichos parámetros se pueden monitorizar por medio de la medición de parámetros, otros pueden requerir una estimación por medio de mediciones de otros parámetros y modelado apropiado, es decir, mediciones virtuales. Se puede usar además información adicional relacionada con las actividades del paciente para modificar, ajustar o corregir el tratamiento de la diabetes. Los ejemplos incluyen, pero no están limitados a, cantidades de comida, frecuencia de consumo y/o tasas de ejecución, frecuencia, duración y/o carga del ejercicio, frecuencia, duración y/o gravedad de la enfermedad, y similares. Se considera que al menos algunos de los modelos de paciente disponibles por medio del módulo de modelos de paciente 72 que se acaba de describir incorporarán en los mismos uno o más de dichos parámetros fisiológicos y/u otra información, de modo que se puedan usar dichos uno o más modelos para estimar uno o más parámetros fisiológicos que no se puedan medir directamente o que es/son difícil(es) de medir directamente. Los modelos de paciente resultantes proporcionarán la capacidad de monitorizar, dinámica o estáticamente, la fisiología subyacente del paciente, tal como el metabolismo del paciente.

La porción de módulos funcionales 56 incluye además un módulo de validación del modelo 74 que proporciona acceso a uno o más programas de simulación basada en ordenador configurados para analizar uno o más aspectos de un modelo de paciente. Se puede almacenar uno o más programas de simulación, por ejemplo, en la base de datos 24 u otra unidad de memoria, y, en dichos casos, el módulo de validación del modelo 74 proporciona una interfaz para acceder a dichos programas. De forma alternativa o adicionalmente, el módulo de validación del modelo 74 puede contener enlaces a la literatura u otras fuentes de programas de validación del modelo. En cualquier caso, el uno o más programas de simulación basada en ordenador en general analizarán el funcionamiento del modelo de paciente seleccionado en una o más situaciones de prueba específicas, y compararán los resultados con estándares conocidos, con una población más amplia de datos, con resultados de modelos analizados previamente, con resultados estadísticamente esperados, o similares. El uno o más programas de simulación basada en ordenador pueden marcar y/o informar de inconsistencias con la comparación. De forma ilustrativa, el módulo de validación del modelo 74 proporciona acceso a uno o más programas de simulación basada en ordenador que realizan uno cualquiera o más de: i) llevar a cabo simulaciones basadas en ordenador relacionadas con modelos de paciente seleccionados, ii) validar los modelos de paciente seleccionados en uno o más intervalos de funcionamiento especificados, iii) proporcionar información que facilite un entendimiento del espacio de funcionamiento, limitaciones y fuentes de error para los modelos de paciente seleccionados, iv) aplicar un caso de uso específico a los modelos de paciente seleccionados y analizar los resultados del modelo, v) someter a prueba los modelos de paciente seleccionados con datos clínicos que se hayan obtenido previamente, y similares.

El módulo de validación del modelo 74 puede incluir uno o más submódulos que proporcionan herramientas analíticas particulares para evaluar los modelos de paciente seleccionados. Los ejemplos de dichos uno o más submódulos con herramientas analíticas pueden incluir, pero no deberían estar limitados a, uno o más submódulos para someter a prueba situaciones de los casos de uso particulares, uno o más submódulos para someter a prueba el modelo de paciente en uno o más intervalos de funcionamiento especificados, uno o más submódulos para analizar estadísticamente los modelos de paciente seleccionados, y similares. El uno o más submódulos para someter a prueba situaciones de los casos de uso particulares pueden proporcionar de forma ilustrativa acceso al uno o más programas informáticos que ejecutan el modelo de paciente de manera que compare una o más características del modelo identificado con estándares predeterminados como se describe anteriormente. El uno o más submódulos para someter a prueba el modelo de paciente en uno o más intervalos de funcionamiento especificados pueden proporcionar de forma ilustrativa acceso al uno o más programas informáticos que analizan el modelo de paciente en uno o más intervalos de funcionamiento especificados para determinar cuán bien el modelo de paciente simula la enfermedad subyacente y/o cuán bien el modelo de paciente simula la reacción de la enfermedad subyacente con respecto al tratamiento recetado, en intervalos de funcionamiento y/o condiciones variables. El uno o más submódulos para analizar estadísticamente los modelos de paciente seleccionados pueden proporcionar de forma ilustrativa acceso al uno o más programas informáticos que ejecutan el modelo de paciente para generar una o más soluciones del modelo de manera que permita la determinación de si la solución/soluciones es/son representativa(s) de una o más características estadísticas esperadas.

El módulo de conjuntos de reglas/directrices 78 puede proporcionar de forma ilustrativa conjuntos de reglas que dirigen el funcionamiento de uno o más de los submódulos, y/o proporcionar directrices en relación con la aplicabilidad o inaplicabilidad particular de un programa de simulación basada en ordenador sobre otro para un modelo de paciente particular, tipo de modelo, intervalo de funcionamiento del modelo y/o situación de uso, en relación con limitaciones en el uso de cualquier programa de simulación particular, en relación con enlaces a fuentes donde se pueden encontrar programas de simulación basada en ordenador pertinentes y/o en relación con enlaces a fuentes donde el trabajo del programa de simulación basada en ordenador pertinente puede estar en proceso de desarrollo, y similares.

La porción de módulos funcionales 56 del programa informático 50 (FIG. 3) incluye además un módulo de análisis 76 que proporciona acceso a una o más herramientas de análisis, al menos algunas de las cuales residen en la base de datos 24 u otra unidad de memoria en forma de uno o más paquetes de programa informático matemáticos convencionales que son accesibles por medio de la porción de aplicaciones de núcleo 54 como se describe anteriormente en el presente documento. Los ejemplos generales incluyen, pero no están limitados a, una o más herramientas de optimización, una o más herramientas de análisis estadístico, una o más herramientas de simulación, una o más herramientas de sensibilidad, una o más herramientas de visualización y una o más herramientas para extraer información (tales como herramientas de reconocimiento de patrones convencionales, herramientas de reconocimiento envolventes, y similares). Los ejemplos específicos incluyen, pero no están limitados a, uno cualquiera o más de LAPACK, un paquete de álgebra lineal, herramientas y bibliotecas de programa informático de IMSL (Independent Media Solutions Limited), herramientas cliente/servidor de OPTIMA, herramientas estadísticas de STATs , herramientas de presentación gráfica, y similares.

El módulo de análisis 76 puede poner a disposición además otras herramientas de análisis y/o visualización de los datos, una o más de las cuales pueden ser específicas para el tratamiento que se intenta desarrollar. Cualquiera de dichas otras herramientas de análisis y/o visualización se puede almacenar en la base de datos 24 u otra unidad de memoria, y se puede acceder directamente por medio del módulo de análisis 76, o puede estar disponible en otro lugar y se puede acceder indirectamente por medio de enlaces pertinentes a dichas herramientas por medio del módulo de análisis 76. De forma ilustrativa, las herramientas matemáticas del núcleo que pueden ser accesibles por medio del módulo de análisis 76 pueden incluir, pero no están limitadas a, i) una o más herramientas de optimización, ii) una o más herramientas de análisis estadístico, iii) una o más herramientas de simulación, iv) una o más herramientas de sensibilidad, v) una o más herramientas de visualización, y vi) una o más herramientas para extraer información, por ejemplo, por medio del reconocimiento de patrones o similares. En un modo de realización, el módulo de análisis 76 proporciona herramientas de análisis que posibilitan que el sistema realice al menos uno de simulaciones, análisis estadístico, análisis de sensibilidad, visualizaciones, extracción de información, optimizaciones, y proporcione recomendaciones que incluyan al menos una de tipo, cantidad y horario para la dosificación, el ejercicio y las comidas. Cada recomendación en un modo de realización puede incluir acciones en una hora actual, en una futura toma o en momentos determinados por el análisis o en momentos determinados por el usuario final.

El módulo de conjuntos de reglas/directrices 78 puede proporcionar de forma ilustrativa conjuntos de reglas que dirigen el funcionamiento de uno o más de los análisis y/u otras herramientas disponibles por medio del módulo de análisis 76, y/o proporcionar directrices en relación con la aplicabilidad o inaplicabilidad particular de una de dichas herramienta sobre otra para una herramienta particular, del tipo de herramienta, de cualquier limitación en el uso de cualquiera particular, en relación con enlaces a fuentes donde se pueden encontrar análisis, visualización u otras herramientas pertinentes y/o en relación con enlaces a fuentes donde el trabajo pertinente en dicho análisis, visualización u otras herramientas puede estar en proceso de desarrollo, y similares.

Usando las herramientas disponibles por medio del módulo de análisis 76, se pueden aplicar los datos específicos del paciente que se han obtenido de acuerdo con uno o más de los protocolos en el módulo de protocolos de obtención de datos 70 a uno o más modelos de paciente seleccionados, seleccionados por medio del módulo de modelos de paciente 72 y validados por medio del módulo de validación del modelo 74, para extraer información fisiológica útil específica del paciente. Entonces, se puede usar la información fisiológica específica del paciente útil para desarrollar uno o más tratamientos para tratar la enfermedad específica del paciente. En el contexto del tratamiento de la diabetes, por ejemplo, las herramientas disponibles por medio del módulo de análisis 76 pueden incluir, pero no deberían estar limitadas a, herramientas de programa informático que proporcionan la extracción de información, tales como valores de parámetro del modelo, herramientas de programa informático que proporcionan el análisis de datos relacionados con la diabetes, herramientas de programa informático de optimización, herramientas de programa informático de análisis de tendencias, herramientas de programa informático que proporcionan la determinación y/o recomendación de la dosificación basal y de inyección intravenosa rápida, herramientas de programa informático que proporcionan la determinación y aplicación de avisos para condiciones tales como hipoglucemia e hiperglucemia, herramientas de programa informático que proporcionan el desarrollo de una o más interfaces gráficas que permiten la introducción por el paciente de datos relacionados con el paciente, y similares.

Una herramienta de programa informático de ejemplo que proporciona el desarrollo de una o más interfaces gráficas que permiten la introducción por el paciente de datos relacionados con el paciente se describe en la solicitud de EE. UU. pendiente de tramitación con n.° de serie__________ titulada PATIENT INFORMATION INPUT INTERFACE FOR A THERAPY SYSTEM, y que tiene el n.° de expediente del apoderado ROP0014PA/37554.20/ WP23627US, que está asignada al cesionario de la presente divulgación, y cuya divulgación se incorpora en el presente documento por referencia. Otra es la descrita en la solicitud de EE. UU. pendiente de tramitación n.° 11/297,733, titulada SYSTEM AND METHOD FOR DETERMINING DRUG ADMINISTRATION INFORMATION, que está asignada al cesionario de la presente divulgación, y cuya divulgación se incorpora en el presente documento por referencia. Otras herramientas de programa informático que proporcionan el desarrollo de una o más interfaces gráficas que permiten la introducción por el paciente de datos relacionados con el paciente se les ocurrirán a los expertos en la técnica, y dichas otras herramientas de programa informático se contemplan por la presente divulgación.

La porción de módulos funcionales 56 del programa informático 50 (FIG. 2) incluye además un módulo de control de controladores del dispositivo 80 que proporciona acceso a uno o más controladores del dispositivos como se describe anteriormente en el presente documento con respecto a la porción de aplicaciones de núcleo 54. También se incluye un módulo de validación y presentación de los resultados 82 que proporciona el análisis y la validación de los resultados de la aplicación de los datos específicos del paciente al uno o más modelos de paciente seleccionados, y que proporciona una o más herramientas para presentar visualmente dichos resultados. Por ejemplo, el módulo 82 puede proporcionar acceso a una o más herramientas de simulación que se pueden seleccionar y ejecutar para someter a prueba los casos críticos en cuanto a la solidez del tratamiento, evaluar la estabilidad de la solución, determinar y evaluar la sensibilidad del tratamiento con respecto a la variación de los parámetros y/o genere un intervalo de confianza realizando un gran número de simulaciones y/o dar una indicación de que el resultado del tratamiento se encuentra en un determinado intervalo. De forma alternativa o adicionalmente, el módulo puede proporcionar acceso a una o más herramientas que se pueden seleccionar y ejecutar para proporcionar una o más protecciones en caso de fallos para garantizar un uso seguro y sólido de los resultados, un análisis de la eficacia de los resultados, por ejemplo, eficacia, potencia, afinidad, un análisis de los resultados para la convergencia y estabilidad de los tratamientos, uno o más biomarcadores basados en ordenador, por ejemplo, HbA1C, una o más programaciones de monitorización del paciente, una o más sugerencias de tratamiento, y similares. El módulo 82 puede proporcionar además acceso a una o más herramientas o paquetes de programa informático de presentación visual para presentar gráficamente los resultados en cualquier formato convencional, por ejemplo, informe de texto, diagramas, gráficas, etc. Un ejemplo específico que ilustra un procedimiento de acuerdo con la presente invención que usa el sistema 10 de la FIG. 1 y el programa informático 50 de las FIGS. 2 y 3 se proporciona en lo sucesivo.

Ejemplo de implementación del procedimiento

Haciendo referencia ahora a la FIG. 4, se muestra un diagrama de flujo de un modo de realización ilustrativo de un procedimiento 100 para desarrollar tratamientos específicos del paciente. El procedimiento 100 ayuda a garantizar que se cumplen reglas mínimas para un tratamiento, la selección de una opción/opciones es pertinente para lograr un objetivo del tratamiento y que se abordan problemas específicos para mejorar el tratamiento del paciente. No es necesario que el procedimiento 100 se ejecute en su totalidad al mismo tiempo, y, en su lugar, se puede acceder en cualquiera de una serie de puntos de entrada, como se describirá con mayor detalle entonces en el presente documento.

Un primer punto de entrada del procedimiento 100 prosigue a la etapa 102, donde se obtienen datos específicos del paciente de acuerdo con uno más de los protocolos de obtención de datos accesibles por medio del módulo de protocolos de obtención de datos 70. Se ha de apreciar que los protocolos de obtención en un modo de realización pueden ser los especificados por órganos médicos rectores, tales como la ADA u organizaciones similares, y, en otros modos de realización, como se establece por un profesional sanitario, tal como un médico de cabecera, médico y similar. En la etapa 102, se pueden obtener datos específicos del paciente introduciendo dichos datos en el ordenador cliente 14 usando uno cualquiera o más modos de realización del dispositivo de medición/obtención de datos del paciente 48 descrito anteriormente en el presente documento con respecto a la FIG. 1. De forma alternativa o adicionalmente, se pueden obtener datos específicos del paciente en la etapa 102 midiendo o de otro modo determinando los datos específicos del paciente de manera convencional, y, entonces, introduciendo dichos datos en el ordenador cliente 14 por medio de uno o más del dispositivo de introducción de datos 40 o el monitor 36 en modos de realización en los que el monitor 36 incluye uno o más botones o conmutadores de pantalla táctil.

Después de la etapa 102, el procedimiento 100 prosigue a la etapa 104, donde se realizan comprobaciones sobre la integridad y calidad de los datos específicos del paciente obtenidos. En un modo de realización, por ejemplo, el módulo de protocolos de obtención de datos 70 incluye, o tiene acceso a, un procedimiento de cumplimiento de los datos en forma de un módulo matemático que comprueba las inconsistencias en los datos obtenidos, y que comprueba los requerimientos definidos para los datos particulares que se han obtenido. Los ejemplos de dichos requerimientos incluyen, pero no están limitados a, la consistencia del registro del tiempo, el/los intervalo(s) de valores de los datos, el/los intervalo(s) de fechas, y similares. En un modo de realización, el procedimiento de cumplimiento de los datos se evalúa previamente para obtener el mejor resultado. Adicionalmente, el módulo de protocolos de obtención de datos 70 puede incluir, o tener acceso a, por ejemplo, un procedimiento de calidad de los datos en forma de un módulo matemático que examina la calidad de los datos obtenidos en términos de su rendimiento y/o propiedades estadísticas. Por ejemplo, para determinar si la calidad de los datos es deficiente, el sistema examina varios aspectos de los datos obtenidos. En este modo de realización, un aspecto es la pertinencia de los datos obtenidos en los que se emplea una consulta de pertinencia llamada desde un módulo de base de datos que consiste en consultas para extraer el contenido de los datos de los datos obtenidos. El contenido de los datos extraído se analiza estadísticamente, por medio de un módulo estadístico apropiado que recibe el contenido de los datos extraído y genera resultados, en relación con la frecuencia de las mediciones por día, la hora de la comida, la inyección intravenosa rápida, la magnitud de la inyección intravenosa rápida con respecto al tamaño de la comida, etc. con respecto a un valor de referencia deseado. Otro aspecto es el horario de los datos obtenidos, donde en la etapa 104 se examina una serie temporal de datos en términos de comparación de un valor de referencia de los requerimientos frente a lo que el paciente ha obtenido para proporcionar un intervalo de confianza para los datos obtenidos. En el modo de realización ilustrado, el ordenador cliente 14 u ordenador servidor 12 se puede hacer funcionar para realizar dichas comprobaciones en la etapa 104 accediendo y ejecutando uno o ambos módulos de cumplimiento de los datos y calidad de los datos.

Después de la etapa 104, opcionalmente el procedimiento 100 puede incluir presentar al usuario las recomendaciones en el monitor 36 para proceder a seleccionar una acción y un estado de disponibilidad de los datos en base a una evaluación actual de la calidad de los datos y la disponibilidad de determinados datos en los datos obtenidos en la etapa 105. Un análisis que proporciona mayores detalles sobre esta etapa se proporciona en una sección posterior. Entonces, el procedimiento 100 prosigue a la etapa 106, donde el ordenador cliente 14 u ordenador servidor 12 se puede hacer funcionar para determinar si las comprobaciones sobre la integridad de los datos y/o calidad de los datos de cada protocolo de obtención de datos han pasado o fallado (o han pasado/fallado en base a la recomendación seleccionada y el estado de disponibilidad de los datos en la etapa 105). Si una o más comprobaciones sobre la integridad y/o calidad de los datos han fallado, prosigue la ejecución del algoritmo, en el modo de realización ilustrado, de vuelta a la etapa 102, de modo que se pueda obtener un nuevo conjunto de datos específicos del paciente de acuerdo con el uno o más protocolos de obtención de datos fallidos. Opcionalmente, como se muestra en la FIG. 4, el procedimiento 100 puede incluir una etapa 108 adicional entre la rama "FALLA" de la etapa 106 y la etapa 102. En este modo de realización, el ordenador cliente 14 u ordenador servidor 12 se puede hacer funcionar en la etapa 108 para identificar solo los datos que se necesitan obtener de nuevo, es decir, los datos en uno cualquiera o más protocolos de obtención de datos que están dañados o que de otro modo no pasan las comprobaciones sobre la integridad y/o calidad de los datos. Después de esto, en la etapa 102, solo se necesitan obtener de nuevo los datos identificados en la etapa 108. En otro modo de realización, se proporciona una etapa de opción 110, en la que se pregunta al usuario si se necesitan introducir de nuevo los datos identificados en este momento. Si la respuesta es sí, entonces, el procedimiento 100 procede de nuevo a la etapa 102, de otro modo el procedimiento 100 continúa con otro análisis usando los datos disponibles obtenidos en un segundo punto de entrada identificado en la FIG. 4.

El segundo punto de entrada al procedimiento 100 existe entre la rama "PASA" de la etapa 106 y la etapa 120 posterior. Se entenderá que el segundo punto de entrada también puede funcionar como un punto de salida a partir de la ejecución de las etapas 102-108. En cualquier caso, la rama "PASA" de la etapa 106 y/o el punto de entrada 2 prosigue a la etapa 120, donde se selecciona(n) uno o más modelos de paciente apropiados del uno o más modelos específicos del paciente disponibles por medio del módulo de modelos de paciente 72. En la etapa 120, se pueden seleccionar el uno o más modelos de paciente usando el ordenador cliente 12 y/u ordenador servidor 12 a través de una interfaz de usuario adecuada, tal como el dispositivo de introducción de datos 40 (por ejemplo, teclado, dispositivo para apuntar y hacer clic, micrófono u otro dispositivo de introducción de datos por el usuario adecuado). De forma alternativa o adicionalmente, se puede llevar a cabo la etapa 120 usando el ordenador cliente 12 y/u ordenador servidor 12 accediendo a uno o más modelos de paciente por medio de un dispositivo de almacenamiento de memoria externo, tal como un disco compacto con memoria de solo lectura (CD-ROM), disquete, dispositivo de memoria compatible con USB o similar. De forma alternativa o adicionalmente, la etapa 120 se puede llevar a cabo accediendo a un enlace apropiado almacenado en la base de datos 24 u otra unidad de memoria, y, entonces, accediendo al sitio web correspondiente u otra fuente del enlace por medio de un navegador web convencional que forma parte de las aplicaciones de núcleo 54. Si, por otra parte, el enlace almacenado corresponde a una referencia a una o más publicaciones, la etapa 120 se puede llevar a cabo accediendo a las una o más publicaciones, manualmente o bien por medio del ordenador cliente 14 y/u ordenador servidor 12. En cualquier caso, cuando se seleccionan el uno o más modelos de paciente, la etapa 120 incluye además la identificación de los valores de parámetro del modelo usando una cualquiera o más de las técnicas descritas anteriormente en el presente documento. En un modo de realización y con referencia hecha a la FIG. 21, se proporciona y analizada en lo sucesivo un ejemplo para ilustrar la identificación de parámetros del modelo.

Para ilustrar la determinación de los parámetros, se describe un simple ejemplo que indica el procesamiento en la etapa 120, por ejemplo, mediante el modelo de paciente 72 (FIG. 3). Considérese un estudio clínico en el que se trata un paciente de tipo I con un tipo de insulina de acción rápida, tal como, por ejemplo, lispro, usando una bomba de insulina, tal como el dispositivo 48 (FIG. 2). La bomba puede infundir un perfil de insulina basal junto con inyección intravenosa rápida solicitada manualmente. Para el estudio clínico, a la bomba se le proporciona un control por infrarrojos y se puede dirigir de una manera de bucle cerrado mediante un algoritmo de control, tal como, por ejemplo, ALGO 510 (FIG. 5), que se analizará en secciones posteriores. El ensayo clínico consistió en una serie de inyecciones intravenosas rápidas pequeñas y grandes por vía subcutánea usando la bomba. Como tal, se seleccionó un modelo de respuesta al impulso, que se describe por la ecuación (1) como:

El modelo de respuesta al impulso de la ecuación (1) consiste en tres parámetros principales. Estos parámetros son: a que representa aproximadamente el número de compartimentos en los que actúa directamente como filtro, 13 que es el tiempo de la tasa de absorción máxima por volumen de distribución de insulina unitaria, y K es el factor de ganancia. La insulina absorbida se distribuye en el volumen de distribución de insulina del cuerpo. La insulina se utiliza por los tejidos, tales como los músculos, el hígado y también se elimina de la sangre circulante. Una ecuación diferencial (2) que describe el procedimiento completo es aproximadamente:

El primer término r ' es el término de eliminación y simplemente se asume que es linealmente proporcional a la concentración de insulina (descenso exponencial de primer orden). Sin embargo, la constante de tiempo t (min) es desconocida. El segundo término en el lado derecho de la ecuación (2) es un término de convolución entre las inyecciones intravenosas rápidas de insulina infundidas con la función de absorción de insulina. El término proporciona la insulina neta absorbida por unidad de volumen en la circulación mediante una secuencia arbitraria de inyecciones intravenosas rápidas de insulina. Las inyecciones intravenosas rápidas de insulina de entrada u’(t) por U/min = 0,278 u’(t), donde u’(t) está en U/h. Entonces, el problema es determinar los parámetros para la cinética de la insulina específica del paciente. Como se muestra en la FIG. 21, se necesitan las inyecciones intravenosas rápidas de insulina de entrada u ’(t) por U/h y las observaciones de la concentración de insulina de salida c °bservación [k] U/ml (círculos).

El problema se soluciona seleccionando el conjunto de parámetros que, por ejemplo, minimiza el criterio descrito por la ecuación (3) como:

donde c °bservación [/] es la concentración de insulina interpolada iésima en la ventana de tiempo y Cⁱ [/] es la concentración simulada iésima correspondiente. Existen otros criterios de minimización que se pueden usar y dependen del requerimiento del problema. El problema en esta fase desde la perspectiva de solución numérica es un problema estándar. El problema se soluciona usando una de las muchas rutinas de optimización disponibles, como se indica mediante el cuerpo de la aplicación. En este ejemplo, se puede usar una rutina de optimización llamada “fmincon ” de un paquete de programa informático llamado MATLAB®, tal como llamar y proporcionar desde una de las aplicaciones de núcleo 54 (fig. 3). La función "fm/ncorí’ encuentra un mínimo limitado de una función de varias variables. Entonces, la función de minimización limitada se soluciona para los parámetros desconocidos, lo que da como resultado la siguiente solución de parámetros: a = 1,28, @ = 31,1 min, t= 56,7 min y K=1,93.

Después de la etapa 120, el procedimiento 100 prosigue a la etapa 122, donde se realiza un procedimiento de validación del modelo en el uno o más modelos de paciente seleccionados en la etapa 120. En el modo de realización ilustrado, el ordenador cliente 14 y/u ordenador servidor 12 se puede hacer funcionar para llevar a cabo la etapa 122 accediendo a uno o más paquetes de programa informático de validación del modelo desde el módulo de validación del modelo 74. El módulo de validación 74 usa la solución de parámetros total proporcionada en la etapa 122 junto con el protocolo usado en el modelo de paciente seleccionado para esta validación.

Después de la etapa 122, el procedimiento 100 prosigue a la etapa 124, donde el ordenador cliente 14 u ordenador servidor 12 se puede hacer funcionar para determinar si el uno o más modelos de paciente seleccionados en la etapa 120 han pasado la etapa de validación del modelo 122 y, por lo tanto, son modelos de paciente válidos. Si no es así, la ejecución del algoritmo prosigue, en el modo de realización ilustrado, de vuelta a la etapa 120 de modo que se puedan seleccionar uno o más nuevos modelos de paciente. Opcionalmente, como se muestra en una imaginaria FIG.

4A, el procedimiento 100 puede incluir una etapa 126 adicional entre la rama "NO" de la etapa 124 y la etapa 120. En este modo de realización, el ordenador cliente 14 u ordenador servidor 12 se puede hacer funcionar en la etapa 126 para identificar solo la porción de un modelo (o modelos) y/o valores de parámetro del modelo que requieren modificación. Después de esto, en la etapa 120, solo se necesita seleccionar la porción identificada del modelo de paciente en la etapa 120 y/o solo los parámetros del modelo identificado requieren modificación.

Un tercer punto de entrada al procedimiento 100 existe entre la rama "SÍ" de la etapa 124 y la etapa 140 posterior. Se entenderá que el tercer punto de entrada también puede funcionar como un punto de salida a partir de la ejecución de las etapas 120-126. En cualquier caso, la rama "SÍ" de la etapa 124 y/o el punto de entrada 3 prosigue a la etapa 140, donde los datos específicos del paciente que se han obtenido durante un periodo de tiempo prolongado de conformidad con las etapas 102-108 se aplican al uno o más modelos de paciente validados que resultan de las etapas 120-126 para determinar uno o más tratamientos del paciente o acciones de tratamiento. La etapa 140 se puede llevar a cabo por medio del ordenador cliente 14 y/u ordenador servidor 12 usando una cualquiera o más de las herramientas de análisis accesibles por medio del módulo de análisis 76 como se describe anteriormente. El uno o más tratamientos del paciente o acciones de tratamiento pueden ser o incluir, por ejemplo, pero no están limitados a, la administración de uno o más fármacos, una recomendación de ejercicio y/u otros tratamientos y/o acciones de tratamiento como se describe anteriormente en el presente documento.

Después de la etapa 140, el procedimiento 100 prosigue a la etapa 142, donde se lleva a cabo un análisis de validación con respecto al uno o más tratamientos del paciente y/o acciones de tratamiento que resultan de la etapa 140. En el modo de realización ilustrado, el ordenador cliente 14 y/u ordenador servidor 12 se puede hacer funcionar para llevar a cabo la etapa 142 accediendo a uno o más paquetes de programa informático de validación de los resultados desde el módulo de validación y presentación de los resultados 82 como se describe anteriormente en el presente documento. Después de la etapa 142, el procedimiento 100 prosigue a la etapa 144, donde el ordenador cliente 14 u ordenador servidor 12 se puede hacer funcionar para determinar si el uno o más tratamientos del paciente y/o acciones de tratamiento determinados en la etapa 140 han pasado la etapa de validación del tratamiento 142 y, por lo tanto, son tratamientos y/o acciones de tratamiento válidos. Si no es así, la ejecución del algoritmo prosigue, en el modo de realización ilustrado, de vuelta a la etapa 140, de modo que se puedan seleccionar uno o más nuevos tratamientos del paciente y/o acciones de tratamiento. Opcionalmente, como se muestra en la FIGS. 4, el procedimiento 100 puede incluir una etapa 146 adicional entre la rama "NO" de la etapa 144 y la etapa 140. En este modo de realización, el ordenador cliente 14 u ordenador servidor 12 se puede hacer funcionar en la etapa 146 para identificar una o más porciones del uno o más tratamientos del paciente y/o acciones de tratamiento que requieren modificación. Después de esto, en la etapa 140, solo se necesitan modificar la porción o porciones identificadas del uno o más tratamientos del paciente y/o acciones de tratamiento en la etapa 140.

Un cuarto punto de entrada al procedimiento 100 existe entre la rama "SÍ" de la etapa 144 y la etapa 160 posterior. Se entenderá que el cuarto punto de entrada también puede funcionar como un punto de salida a partir de la ejecución de las etapas 140-146. En cualquier caso, la rama "SÍ" de la etapa 144 y/o el punto de entrada 4 prosigue a la etapa 160, donde el uno o más tratamientos del paciente y/o acciones de tratamiento se presenta(n) al usuario del sistema 100 por medio de uno o más dispositivos y/o formatos de presentación como se describe anteriormente en el presente documento. La etapa 160 se puede llevar a cabo por medio del ordenador cliente 14 y/u ordenador servidor 12 usando uno cualquiera o más de los paquetes de programa informático de presentación accesibles por medio del módulo de validación y presentación de los resultados 82 como se describe anteriormente en el presente documento.

Ejemplos de casos de uso específicos - Ejemplo A

Lo siguiente es un ejemplo de caso de uso de algunos de los conceptos descritos en el presente documento. Las etapas de este ejemplo en general siguen el algoritmo 100 de la FIG. 4, y se pueden implementar por medio de un asistente convencional, es decir, una interfaz de usuario de ordenador por medio de la que se guía al usuario a través de una secuencia de diálogos para realizar una tarea. El asistente es una mezcla de recopilación y clasificación de información del paciente diabético con el objetivo de orientar al profesional sanitario hacia (i) el objetivo final de la determinación del tratamiento y/o (ii) los resultados intermedios, como se muestra en el diagrama de flujo de la FIG.

4. El siguiente ejemplo se presentará en el marco de las etapas ejecutados por dicho asistente, aunque se entenderá que las etapas de este ejemplo se pueden implementar de forma alternativa por medio de una receta o conjunto de instrucciones convencionales.

En este primer ejemplo, el archivo de la historia clínica y el estado actual del paciente son como sigue. El sujeto es un paciente diabético de tipo I cuya última visita al profesional sanitario fue hace 4 meses. El sujeto es un hombre de 40 años, que pesa 80 kg (sin cambio desde la última visita), y actualmente está usando una insulina de acción rápida, tal como lispro (sin cambio desde la última visita). Según parece el sujeto mide la bG en promedio 3 veces por día (sin cambio desde la última visita). Los valores de cantidades de comida medios para la visita previa son 35 g, 70 g, 85 g y 25 g, y los valores de cantidades de comida actuales son desconocidos. La proporción de carbohidrato con respecto a insulina del sujeto es de 8 g/U (sin cambio) y la sensibilidad a la insulina es de 40 m/dl/U (sin cambio). La actividad física del sujeto es normal (sin cambio). En la visita previa del sujeto, su HbA1C fue de 7,5, y actualmente es de 9,5. Bajo este patrón de hechos, el profesional sanitario se dirige a seguir un protocolo de obtención de datos clásico para diabéticos de tipo I típicos.

En la etapa 102, se solicita al usuario por el asistente que seleccione el tipo de diabetes del paciente. Las opciones son de tipo I o bien de tipo II. En este ejemplo, la selección es de tipo I. Luego, se solicita al usuario por el asistente que seleccione el motivo de la visita. Las opciones disponibles son: nuevo paciente, ensayo clínico, visita regular, que normalmente es una visita cada 2-3 meses, hospitalización posterior o monitorización intensiva completada. En este ejemplo, la selección es la visita regular. Entonces, el asistente solicita al usuario las siguientes introducciones de datos y, si está disponible, realiza las siguientes acciones a través de protocolos de recuperación de mensajes/datos estándar: introducir la altura, peso, sexo, edad del paciente; obtener informes de laboratorio pertinentes (A1C, LDL, HDL, BP, medicamentos); descargar datos de dispositivos pertinentes: datos del medidor, datos de la bomba, PDA, y similares; capturar el comportamiento del paciente (a partir de datos obtenidos, la captura del estilo de vida), tal como, por ejemplo, número de acontecimientos de hipoglucemia, número de acontecimientos de hiperglucemia, distribución de los horarios de las comidas, composición de los carbohidratos, distribución de insulina, actividad física, patrón de sueño y horario de trabajo; criterio de exclusión; estado fisiológico de entrada (enfermedad, sin enfermedad); medicamentos de entrada; CSII; MDI; tratamiento actual; y reglas de tratamiento actual. En este ejemplo, los datos obtenidos reflejan que: HbA1C actual = 9,5; última HbA1C = 7,5; (últimos valores medios 35 g, 70 g, 85 g, 25 g); la información sobre las comidas actual es desconocida debido a la carencia de datos introducidos; las mediciones de bG son pocas; la media de bG y DE son: (150+/-70); y que el ayuno nocturno es desconocido, así como los restantes valores de datos.

En base a los datos introducidos/obtenidos anteriormente, en la etapa 104, entonces, el sistema comprueba la integridad de los datos/calidad de los datos. En este ejemplo, puesto que era una visita regular, el profesional sanitario había determinado previamente que se necesita un ajuste regular del tratamiento del paciente como objetivo del tratamiento. En consecuencia, durante esta etapa se examinan diversos aspectos. Por ejemplo, para algunos objetivos del tratamiento seleccionados, existen requisitos previos de obtenciones de datos necesarios para proporcionar un resultado significativo hacia la consecución del objetivo del tratamiento seleccionado. En consecuencia, en esta etapa, el sistema comprueba para ver si están disponibles datos en los datos obtenidos que también sean sensibles (por ejemplo, en un intervalo predeterminado, por encima/debajo hay un determinado valor, etc.) para parámetros de algoritmo particulares. Además, en la etapa 104, el contenido de los datos se analiza estadísticamente para determinar la frecuencia de las mediciones por día, el intervalo de horas de la comida, el intervalo de inyección intravenosa rápida para la comida, la magnitud de la inyección intravenosa rápida promedio con respecto al tamaño de la comida, etc.

También se examinan series temporales en los datos obtenidos. La idea es que el paciente siga normalmente un patrón diario que consiste en actividades que incluyen la comida, la actividad física y el horario de trabajo. Según la información sobre la actividad física del estilo de vida del paciente, la información sobre las comidas, la secuencia de mediciones y la información sobre la dosificación obtenidas por el paciente, los detalles de dicha información variarán en cualquier día dado. Esta información variada, cuando se analiza durante un periodo de tiempo, proporciona una indicación de la eficacia del tratamiento. En un modo de realización, dicha información obtenida por el paciente se examina con respecto a un estilo de vida del paciente deseado y al menos un mínimo de información que se debe obtener.

Las deducciones lógicas se infieren después del análisis de los datos y el mapeo de los datos para abordar: (a) la pertinencia de un próximo conjunto de análisis, (b) un intervalo de confianza para un resultado; y los (c) criterios de aceptación/rechazo basados en el umbral. Por ejemplo, en un modo de realización, si se consideran los medicamentos del acontecimiento y su influencia en la bG, la primera etapa es determinar si los datos se han obtenido según el protocolo. Se ha de esperar que los datos de bG tengan variabilidad tanto en su magnitud como en la hora de las mediciones. En un modo de realización, el número de mediciones, la secuencia de mediciones y la variabilidad en la medición se comprueban frente a reglas empíricas para determinar la aceptación de los datos. En otro modo de realización, se aplica un conjunto de reglas empíricas para determinar cuál de los datos obtenidos está por debajo de un umbral basado en criterios de aceptación para realizar un determinado análisis para lograr un objetivo deseado. Por ejemplo, para el ejemplo de historia clínica dado anterior, a partir de los datos disponibles y la calidad de control esperada, una generación de reglas empíricas mostrará que las mediciones de bG necesarias para el control de la glucosa posprandial son altamente pertinentes para el objetivo de ajustar el tratamiento del paciente y que se necesita la obtención de mediciones de bG mínimas para proporcionar recomendaciones útiles para lograr ese objetivo. Si la obtención de la medición de bG está por debajo del mínimo, entonces, en la etapa 106 la calidad de la obtención de datos fallará en este ejemplo.

Después de realizar las comprobaciones en la etapa 104, se proporciona opcionalmente una serie de evaluaciones/recomendaciones del tratamiento para el paciente en la etapa 105. Se proporciona una calificación de pertinencia junto con cada evaluación/recomendación del tratamiento que se basa en la selección del efecto de dicha evaluación/recomendación del tratamiento en base a la calidad de los datos obtenidos que tendrá para generar cambios en el tratamiento del paciente. En el ejemplo dado, dicha evaluación/recomendación del tratamiento y su pertinencia asociada puede incluir: (a) la obtención para el tratamiento del paciente es deficiente (pertinencia de un 95 %), (b) el paciente necesita ajustes del tratamiento regulares (pertinencia de un 50 %) y (c) cambio del estilo de vida del paciente (pertinencia de un 15 %). Para la recomendación (a), el resultado de las reglas empíricas da lugar a la conclusión de que, a partir de los datos obtenidos, A1C es deficiente, el paciente se siente mal, las lecturas indican grandes valores de glucosa, muchos episodios de hiperglucemia e hipoglucemia, y no hay suficientes mediciones de bG para ajustar eficazmente el tratamiento del paciente. En consecuencia, la calificación de alta pertinencia se basa en las consideraciones de que los nuevos datos obtenidos son limitados y los datos antiguos tienen una antigüedad de aproximadamente 4-5 meses. Para la recomendación (b), como se menciona anteriormente, para ajustar el tratamiento del paciente, se necesita ponderar la A1C con un número suficiente de mediciones de glucosa prepandriales y mediciones posprandiales. El procedimiento también pondera los episodios de hiperglucemia e hipoglucemia, y el valor de A1C. Sin embargo, puesto que no hay suficientes mediciones de bG presentes en los datos obtenidos y A1C es insatisfactoria, la pertinencia para esta recomendación es baja y, por tanto, probablemente no sea la mejor opción dado el alcance de los datos obtenidos. Cuando el paciente puede proporcionar más mediciones de bG, entonces, la pertinencia de esta recomendación se incrementaría. Para la recomendación (c), observar los cambios del estilo de vida de un paciente (por ejemplo, medicamentos, mudarse/viajar a una nueva zona horaria, cambiar la actividad física, cambiar los niveles de estrés o cambiar la ingesta de comidas), comparando principalmente los datos históricos comparando los valores promedio y/o usando ventanas móviles y comparando los valores promedio y/o determinando las tendencias en los datos, en este punto, debido a la deficiente obtención de datos, proporcionaría poco o ningún valor al profesional sanitario en la realización de ajustes en el tratamiento del paciente.

Se ha de apreciar que se puede proporcionar una gran cantidad de evaluaciones/recomendaciones del tratamiento en base a los diversos datos obtenidos. Por ejemplo, dichas evaluaciones/recomendaciones del tratamiento podrían incluir que el paciente sea un diabético de tipo I recién diagnosticado y necesite tratamiento, o que el paciente de tipo I se incluya en un ensayo clínico de bucle cerrado. En el ejemplo dado, dichas recomendaciones tienen una pertinencia de un 0 %, puesto que el paciente ni es un nuevo tipo I ni se ha incluido para un ensayo clínico de bucle cerrado. Estas evaluaciones/recomendaciones del tratamiento generadas se presentan, entonces, como una salida de datos en la etapa 105 para la selección por el profesional sanitario. En el ejemplo proporcionado, el profesional sanitario selecciona la evaluación/recomendación del tratamiento (a), que es que la obtención para el tratamiento del paciente es deficiente. La evaluación/recomendación del tratamiento (b) y (c) puede ser útil para el profesional sanitario en cierto nivel, pero la calificación de pertinencia aclara que los datos globales carecen de los datos obtenidos y no son lo suficientemente buenos como para generar un nuevo tratamiento.

Luego, después de la selección de una de las evaluaciones/recomendaciones enumeradas, entonces, también se proporciona un estado de disponibilidad de los datos al profesional sanitario para la selección en la etapa 105. En esta etapa, el sistema también determina para la evaluación/recomendación seleccionada (aquí, en este ejemplo, la evaluación/recomendación del tratamiento (a)), qué otros tipos de acciones, si se toman, son pertinentes para abordar/resolver/mejorar la evaluación/recomendación del tratamiento seleccionado. En este ejemplo, se proporcionan los siguientes estados de disponibilidad de los datos para la selección: (i) obtener datos para mejorar el control de la glucosa posprandial (pertinencia de un 80 %), (ii) obtener datos para mejorar la glucosa objetivo durante el ayuno (pertinencia de un 75 %), (iii) obtener datos para tener parámetros del tratamiento global iniciales (pertinencia de un 70 %), (iv) alterar los horarios del tratamiento, tales como debidos al cambio de zona horaria (pertinencia de un 25 %), (v) alterar el tratamiento para ajustar la actividad física creciente, estado alternativo (pertinencia de un 15 %), (vi) alterar el tratamiento para ajustarse a un estado fisiológico alternativo (pertinencia de un 5 %) y (vii) identificar parámetros para el algoritmo de bucle cerrado (pertinencia de un 0 %). En este ejemplo, otras reglas empíricas determinan, a partir de los datos obtenidos y la evaluación/recomendación seleccionada, que para mejorar de la mejor manera el control de la glucosa posprandial y para ser útil en el cambio del tratamiento que se necesitan obtener más de dichos datos y dichos datos son los más pertinentes para lograr ese objetivo. Sin embargo, en este ejemplo, el profesional sanitario considera y selecciona la opción (iii): obtener datos para tener parámetros del tratamiento global iniciales decidiendo qué es lo mejor para comenzar desde una solución estándar.

A partir de las diversas selecciones, por tanto, los datos obtenidos no son cumplidores y fallan en la etapa 106. Por ejemplo, en este modo de realización particular, para ajustar el tratamiento del paciente, se necesita ponderar la HbA1c con una medición de glucosa prepandrial y una medición posprandial. Sin embargo, puesto que están disponibles pocas mediciones de glucosa en los datos obtenidos para que el algoritmo los use eficazmente, esta carencia de datos necesarios dará como resultado que la calidad de los datos falle en la etapa 106. Entonces, el asistente ejecuta la etapa 108, donde el sistema por medio de otro conjunto de reglas empíricas identifica los datos que se necesitan obtener para proporcionar suficientes datos para los parámetros del tratamiento iniciales necesarios para ajustar el tratamiento del paciente como un plan de tratamiento recomendado o receta. La receta puede abordar uno o más de los siguientes: (a) número de mediciones de bG, (b) recuento de carbohidratos, (c) horario de medición; (d) notificación en un dispositivo, (e) recomendación de entrenamiento, (f) criterios de satisfacción sobre el cumplimiento, (g) hora de la próxima visita —el protocolo puede dictar una fecha o duración— y (h) punto de entrada potencial en la próxima visita. En el ejemplo dado, la salida de datos como receta proporcionada en la etapa 108 es: se necesitan 3+ mediciones prepandriales de bG por día para satisfacer el cumplimiento, se documentará el recuento de todos los carbohidratos ingeridos, la notificación en el dispositivo por insistencia del médico, guía de ayuda para el recuento de carbohidratos recomendada (o una clase de entrenamiento/actualización), la próxima visita es en 3 semanas desde la fecha de la visita actual, y el punto de entrada 1 debe ser cuando el paciente acude a la próxima visita. Después de la etapa 108, el asistente opcionalmente realiza una comprobación para ver si los datos identificados se han de introducir de nuevo en la etapa 110. Si es así, entonces, el asistente repite la etapa 102 para los datos identificados. Si no es así, el asistente en este punto continúa con el algoritmo 100 en el punto de entrada 2. El problema para el profesional sanitario es si todavía el paciente tiene buenos parámetros del tratamiento que no se han solucionado. Aunque las etapas de obtención previas han indicado la carencia de datos necesarios y han presentado al paciente los requerimientos de obtención de datos necesarios para mejorar el rendimiento, en la etapa 120 se presentan al usuario en este ejemplo ilustrado las opciones: (a) continuar con los mismos parámetros, (b) usar datos históricos, o (c) reinicializar los datos para examinar los parámetros del tratamiento actual. Se ha de apreciar que se pueden seleccionar las etapas opcionales 105 y 110 (en conjunto o individualmente) para su uso durante la configuración del programa informático, lo que se ha producido en este ejemplo.

En la etapa 120, un algoritmo de pertinencia proporciona la pertinencia de cada opción al ser útil para resolver la cuestión de si el paciente tiene buenos parámetros del tratamiento. En este ejemplo, la opción de uso de los mismos parámetros (opción (a)) es de un 0 %, puesto que las etapas previas han indicado que la calidad de los datos era deficiente y que las opciones de uso de los datos históricos (opción (b)) y de reinicialización de los datos (opción (c)) son de un 60 % y un 80 %, respectivamente. Para proporcionar la pertinencia de cada opción, el algoritmo de pertinencia en la etapa 120 en un modo de realización considera la siguiente información: datos del paciente insuficientes para rehacer los parámetros del tratamiento; los datos históricos del paciente están disponibles; y los modelos de inicialización del tratamiento están disponibles. El algoritmo de pertinencia pondera el control glucémico del paciente para determinar los parámetros del tratamiento y también cómo le fue al paciente con la estimación inicial de los parámetros del tratamiento cuando el paciente se analizó por primera vez por el sistema. Sin embargo, el sistema le permite al profesional sanitario usar su propio juicio en cada etapa, puesto que a veces el sistema puede ser demasiado conservador o arriesgado para el paciente actual. En este ejemplo, el profesional sanitario selecciona la opción (c) “reinicializar datos” en la etapa 120, lo que da como resultado que el análisis y la indicación del mode lo sean válidos en las etapas 122 y 124. Estas etapas indicadas simplemente significan que los parámetros basados en la población se seleccionaron por el profesional sanitario, y esto, de forma predeterminada, representa el comportamiento medio de la población con el que el profesional sanitario está de acuerdo considerando el estado actual de la información.

Después de la etapa 124, el asistente continúa con el algoritmo 100 en el punto de entrada 3. En la etapa 140, el procedimiento 100 en este modo de realización aplica los datos obtenidos a parámetros basados en la población para determinar un tratamiento del paciente, y que se muestran en la tabla 1.

Tabla 1 - Parámetros del tratamiento generados a partir del modelo

En la etapa 142, el asistente ahora realiza un análisis de validación sobre el tratamiento del paciente determinado y proporciona al profesional sanitario las opciones más pertinentes con las que revisar el tratamiento del paciente determinado y proporcionar directrices de seguridad del tratamiento. Se proporciona al profesional sanitario en el ejemplo dado la opción de evaluar el impacto sobre el estilo de vida en el control de la enfermedad crónica del paciente. Además, en relación con las directrices de seguridad del tratamiento, en base a los datos obtenidos y los resultados sobre el estilo de vida, se notifica al profesional sanitario en la etapa 142 que el paciente puede sufrir x episodios hipoglucémicos e y episodios hiperglucémicos, por lo que los episodios hiperglucémicos se pueden reducir mediante medición posterior adicional e insulina correctiva. El sistema también recomienda en la etapa 142 un tratamiento en base a los parámetros generados a partir del modelo seleccionado. En este ejemplo, el tratamiento recomendado proporciona fijar la tasa basal a una U/h deseada, fijar la proporción de carbohidrato con respecto a insulina a una g/U deseada, la sensibilidad a la insulina a una mg/dl deseada, indicar un número necesario de mediciones de bG, solicitar el recuento de carbohidratos de todas las comidas ingeridas e indicar que se necesitan al menos x mediciones preprandiales diarias y al menos y mediciones posprandiales para mejorar las estimaciones de los parámetros del tratamiento. Adicionalmente, se avisa al usuario de que el paciente debe completar la obtención de datos para el tratamiento en las próximas semanas y visitar al profesional sanitario después de esto. En la etapa 144, se pregunta al profesional sanitario por el sistema si el tratamiento recomendado es válido. Si el profesional sanitario desea cambiar cualquiera de los aspectos anteriores del tratamiento recomendado, entonces, indicando "no" en la etapa 144 da como resultado que el profesional sanitario pueda modificar una porción del tratamiento en la etapa 146. Después de realizar los cambios deseados en la etapa 146, entonces, se repiten las etapas 140-144. De otro modo, el procedimiento 100 finaliza el tratamiento de recomendación mediante datos de salida como una receta en la etapa 160, que también es el punto de entrada 4. Se ha de apreciar que para este ejemplo, cuando el paciente visita de nuevo al profesional sanitario, el asistente se emplea de nuevo en el punto de entrada 1 y orienta al usuario a través del algoritmo 100 de la FIG. 4.

Ejemplos de casos de uso específicos - Ejemplo B

En un segundo ejemplo de caso de uso, la historia clínica del sujeto es como sigue. El sujeto es el mismo paciente diabético de tipo I que en el ejemplo A anterior y cuya última visita al profesional sanitario fue hace 24 días. El sujeto es un hombre de 40 años, que pesa 80 kg (sin cambio desde la última visita), y actualmente está usando una insulina de acción rápida, tal como lispro (sin cambio desde la última visita). El sujeto mide la glucosa en sangre (bG) en un promedio de 6 veces por día (3 veces por día a partir de la última visita). Los valores de cantidades de comida medios para la visita previa son 25 g, 85 g, 85 g y 25 g, y los valores de cantidades de comida actuales son desconocidos. La proporción de carbohidrato con respecto a insulina del sujeto es de 8 g/U (sin cambio) y la sensibilidad a la insulina es de 40 mg/dl/U (sin cambio). La actividad física del sujeto es normal (sin cambio). En la visita previa del sujeto, su HbA1C fue de 9,5, y actualmente es de 9,5. Bajo este patrón de hechos, el profesional sanitario se dirige a seguir un protocolo de obtención de datos de monitorización intensiva para diabéticos de tipo I típicos.

Después de completar la etapa 102 en este ejemplo, se han obtenido los siguientes datos: paciente de tipo I; el motivo de la visita es la monitorización intensiva completada; A1C actual = 9,5; última A1C = 9,5; información sobre las comidas actual (media 35 g±5, 70 g±15, 85 g±20, 25 g±15); la última información sobre las comidas es desconocida debido a la carencia de datos; la media de bG y DE son 135±50; el ayuno nocturno es de 130±30 mg/dl; los datos se procesan frente al protocolo requerido; y estadísticamente, los datos obtenidos se realizaron en los límites del protocolo. Después de realizar comprobaciones sobre la integridad y calidad de los datos obtenidos en la etapa 104, la serie de recomendaciones proporcionadas (por ejemplo, presentadas) junto con su calificación de pertinencia en la etapa 105 son como sigue: (a) el paciente necesita ajustes del tratamiento regulares (pertinencia de un 90 %), (b) el tratamiento del paciente es deficiente, por ejemplo, la A1C es deficiente, el paciente se siente mal, las lecturas indican grandes valores de glucosa, muchos episodios de hiperglucemia (pertinencia de un 95 %), (c) el paciente es un diabético de tipo I recién diagnosticado y necesita tratamiento; (pertinencia de un 0 %), (d) el paciente de tipo I se ha incluido para un ensayo clínico de bucle cerrado; (pertinencia de un 0 %), y (f) cambio de estilo de vida del paciente, por ejemplo, mudándose a una nueva zona horaria, incrementar la actividad física, etc. (pertinencia de un 65 %).

A partir de las recomendaciones presentadas anteriormente, el profesional sanitario ve que la recomendación (a) y (b) son las más pertinentes, de las que la recomendación (b) "el tratamiento del paciente es deficiente" tiene la pertinencia más alta. En este ejemplo, el profesional sanitario selecciona la recomendación (b) en la etapa 105. Luego, las siguientes opciones seleccionables sobre el estado de disponibilidad de los datos y la pertinencia asociada se proporcionan (por ejemplo, se presentan) en la etapa 105 al profesional sanitario: (i) obtener datos para mejorar el control de la glucosa posprandial (pertinencia de un 15 %), (ii) obtener datos para mejorar la glucosa objetivo durante el ayuno (pertinencia de un 10 %), (iii) obtener datos para tener parámetros del tratamiento global iniciales (pertinencia de un 10 %), (iv) rehacer los parámetros del paciente y determinar los parámetros del tratamiento (pertinencia de un 95 %), (v) alterar los horarios del tratamiento, por ejemplo, debidos al cambio de zona horaria (pertinencia de un 25 %), (vi) alterar el tratamiento para ajustar la actividad física creciente (pertinencia de un 0 %), (vii) alterar el tratamiento para ajustarse a un estado fisiológico alternativo (pertinencia de un 0 %) y (viii) identificar parámetros para el algoritmo de bucle cerrado (pertinencia de un 0 %). En esta etapa, el profesional sanitario selecciona la opción (iv) rehacer los parámetros del paciente y determinar los parámetros del tratamiento como el modo de acción pertinente. Está claro que la inicialización de la visita anterior muestra que el control glucémico es deficiente. Lo preprandial indica un control de las comidas y/o control del ayuno deficiente, a pesar de que el paciente esté realizando una tarea diligente de obtención de mediciones y recuento de carbohidratos. Se necesita un ajuste específico del paciente, a diferencia de la visita previa en la que se proporcionaron parámetros basados en la población. Puesto que la obtención de datos según el valor de referencia, por tanto, es cumplidora y, por tanto, pasa en la etapa 106, el procedimiento 100 continúa en el punto de entrada 2 para la selección del modelo.

En la etapa 120, el procedimiento 100 proporciona una determinación de que los datos obtenidos están disponibles y son satisfactorios, también están disponibles los datos históricos y que también está disponible un modelo de inicialización empírico. Por tanto, se proporcionan al personal sanitario en este contexto en la etapa 120 las siguientes opciones y su pertinencia asociada: (a) identificar los parámetros del paciente (pertinencia de un 95 %), (b) usar datos históricos (pertinencia de un 50 %) y (c) reinicializar los datos (pertinencia de un 50 %). En este ejemplo, el profesional sanitario selecciona la opción (a), que es identificar los parámetros del paciente. El profesional sanitario podría haber seleccionado el enfoque de uso de los datos históricos, en el que se analizan y presentan patrones y tendencias. Sin embargo, en este ejemplo con datos detallados disponibles, el profesional sanitario opta por una etapa detallado de examen de las características fisiológicas específicas del paciente. Luego, en la etapa 120, se presentan los siguientes parámetros del modelo identificado junto con su pertinencia evaluada como las opciones seleccionables por el profesional sanitario: (a) modelo relacionado con la comida CSII medidor de bG (pertinencia de un 99 %); modelo relacionado con la comida MDI medidor de bG (pertinencia de un 0 %); y modelo relacionado con la comida CSII continuo (pertinencia de un 0 %). En la etapa 140, el profesional sanitario selecciona la primera opción (a), que es comida CSII medidor de bG en el asistente. Aquí, la pertinencia muestra que se necesita el tratamiento global. La comida es la principal perturbación exógena para el paciente. El ejercicio u otros factores estresantes se ponderan en este punto como secundarios, y pueden ser pertinentes en el futuro ajuste de los parámetros del tratamiento.

Finalmente, en la etapa 120, el asistente presenta, para su selección, el tipo de modelo de comida: (a) rápido (dominado por carbohidratos); (b) medio (nominal); (c) lento (alto contenido de grasa), y (d) mixto (los datos obtenidos en consecuencia tendrán dicha información). El profesional sanitario selecciona la opción del segundo modelo de comida (b), que es el modelo de comida medio o nominal. Aquí, los datos no son lo suficientemente abundantes o no están lo suficientemente documentados corresponder a un caso mixto en la opción (d), y los datos del paciente han indicado el modelo nominal de referencia. Se pueden capturar hábitos alimenticios específicos con información más detallada. La sección del modelo de comida puede ser, o incluir, un procedimiento más detallado y, en cualquier caso, da lugar a la selección de modelos matemáticos subyacentes que pueden ser estándar o generalizados permitiendo que un profesional sanitario seleccione o defina modelos fisiológicos alternativos. El ejemplo anterior ilustra solo una forma de abordar la selección del modelo en la etapa 120.

Después de la selección del modelo, en la etapa 122, el procedimiento 100 realiza una validación y un análisis sobre el modelo. Para esta etapa, las situaciones de los casos de uso específicos del paciente se simulan in silico en el sistema 10 por medio de una simulación basada en ordenador. Por muy bueno que pueda ser el entendimiento del modelo de paciente seleccionado, cada vez que se determina un modelo matemático, se debe someter a prueba para evaluar su fidelidad. La etapa 122 garantiza que existen comprobaciones y compensaciones integradas en el sistema 10, puesto que se han sometido a prueba casos de prueba especiales que se han configurado con respecto al sujeto individual, y en los que los datos resultantes se comparan entonces con estándares conocidos o bien con una población de datos más amplia. La etapa 122 supone que al menos uno de los siguientes será dependiente del modelo de paciente seleccionado específico: validar el modelo in silico en el intervalo de funcionamiento especificado para entender el espacio de funcionamiento y entender las limitaciones del modelo; proporcionar una idea razonable del error subyacente a los supuestos dados del modelo; aplicar otros módulos de pruebas, tales como comidas de prueba, dosis de insulina de prueba, etc.; someter a prueba el modelo con datos clínicos que se hayan obtenido, tal como la información de introducción de datos de insulina y la información de introducción de datos de acontecimientos; y aplicar características del modelo específicas, tales como perfiles, intervalos de valores de parámetro o métricas especificados. Cualquier anomalía o aspectos extraños se marcan y presentan al profesional sanitario para que actúe.

En el ejemplo dado, se realiza un ajuste del modelo de paciente que tiene una calidad de ajuste = 85 %, es decir, el modelo y el conjunto de parámetros explicarán un 85 % de las características del modelo, que es un resultado ponderado de las características observadas (mediciones de bG y cantidades de comida). En otros modos de realización, pueden estar disponibles intervalos de confianza para los parámetros. También en este ejemplo, se realiza una respuesta al modelo de paciente simulada para verificar las características fisiológicas (verificación) del modelo. Esto también se denomina caracterización del modelo de paciente, que incluye pruebas estándar del modelo con respecto a señales predeterminadas para examinar las características obtenidas, que, entonces, se comparan frente a uno o más intervalos esperados de las características del paciente observadas. Un objetivo en este punto es mantenerse en los límites especificados de características aceptables del paciente. La capacidad del modelo para duplicar los resultados (calidad de predicción) también se puede realizar en otros modos de realización. Este es un rasgo característico opcional, y se puede llevar a cabo cuando los conjuntos de datos por duplicado estén disponibles.

La medida de esta capacidad, por ejemplo, puede ser un ajuste por mínimos cuadrados normalizado.

Después de completar el análisis sobre el modelo seleccionado en la etapa 122, en la etapa 124 se lleva a cabo una determinación de si el modelo es válido. En la etapa 124, el profesional sanitario revisa y contempla la aceptación del modelo en base a los resultados, lo que incluye al menos uno de los siguientes: intervalo de confianza de los parámetros, capacidad para ajustar los datos, proporcionar estimaciones de los parámetros basados en la fisiología con el intervalo de confianza, y similares. Los intervalos de confianza se pueden computar para cada uno de los parámetros. Estos intervalos de confianza determinan básicamente las confidencias con las que se han computado estos parámetros. No se esperan intervalos de confianza excesivamente amplios, ya que el modelo se ha elegido para el protocolo particular. Pero si ocurre que son demasiado amplios, se puede concluir que para este paciente particular y para esta comida particular, no existe posibilidad de mejora con este procedimiento. Además, se puede comprobar la bondad de ajuste usando criterios clásicos como la diferencia cuadrática entre la predicción y las medidas. Si la bondad de ajuste es deficiente, los parámetros computados no se deben usar para mejorar el control de las comidas. Esta etapa se puede realizar de nuevo si el modelo no realiza un buen trabajo de validación. Adicionalmente, se puede desear realizar una comparación con otro modelo o modelos para determinar si existe un modelo o modelos alternativos que proporcionen mejores resultados. Como resultado del análisis de validación realizado en el modelo seleccionado (es decir, identificar los parámetros del paciente) en la etapa 122, el profesional sanitario determina en la etapa 124 que el modelo es válido. El asistente en este punto continúa con el algoritmo 100 en el punto de entrada 3.

Después de que el profesional sanitario haya aprobado el modelo, entonces, el asistente lleva al profesional sanitario a las fases finales del análisis/determinación del tratamiento. En la etapa 140, el procedimiento realiza simulaciones in silico para cuestionar los casos críticos en cuanto a la solidez del tratamiento y evaluación de la estabilidad de la solución teniendo en cuenta la programación de monitorización y las protecciones en caso de fallos, determinar la sensibilidad del tratamiento con respecto a la variación de los parámetros, generar un intervalo de confianza realizando un gran número de simulaciones y determinar la eficacia (eficacia, potencia, afinidad) de diversos tratamientos para determinar las sugerencias del tratamiento recomendado (incluyendo la seguridad y tolerancia del tratamiento).

Por ejemplo, en la etapa 140, el procedimiento 100 en el ejemplo dado extrae/identifica los datos sobre el estilo de vida del paciente y, en base a dichos datos, proporciona resultados del tratamiento con intervalo(s) de confianza. El estilo de vida del paciente es pertinente aquí para someter a prueba y evaluar un tratamiento. La información obtenida y el modelo identificado se presentan ahora al profesional sanitario por medio del asistente con opciones sobre el estilo de vida para revisar los resultados del tratamiento. Aquí, un objetivo es proporcionar directrices de seguridad del tratamiento. Se pueden proporcionar al personal sanitario las siguientes opciones de cómputo del tratamiento en la etapa 140: (a) determinar los parámetros del tratamiento para un algoritmo A especificado (por ejemplo, CSII) y un estilo de vida especificado; (b) determinar los parámetros del tratamiento para un algoritmo B especificado (por ejemplo, ICT) y un estilo de vida observado; (c) sugerir un tratamiento de alto rendimiento (CSII medición frecuente estilo de vida); y (d) evaluar el impacto sobre el estilo de vida (95 %) con un cumplimiento deficiente, siendo cumplidor en un 50 % frente a un 90 %. En la etapa 140, el profesional sanitario selecciona la primera opción (a), puesto que el paciente no había sido cumplidor en la visita anterior. Opcionalmente, un ejercicio adicional que se puede llevar a cabo por el profesional sanitario también es seleccionar la cuarta opción (d).

Aquí, usando el estilo de vida observado, pero pasando a través de una situación no cumplidora (es decir, el paciente no observa las reglas del tratamiento y/o no es cumplidor con las mediciones y el recuento de carbohidratos), se lleva a cabo una simulación estocástica en la etapa 142, y se genera un informe comparativo de los resultados potenciales. Dicho informe puede incluir: el paciente puede sufrir x episodios hipoglucémicos y/o y episodios hiperglucémicos; HbA1C anticipada en la próxima visita (por ejemplo, 3 meses a partir de ahora); altas y bajas en las mediciones de bG; pérdida de tiempo potencial y días de enfermedad debido a un tratamiento de la diabetes no controlada. Adicionalmente, las recomendaciones con el tratamiento pueden ser: la medición del estilo de vida del paciente debe ser de al menos x mediciones; se pueden disminuir los episodios hiperglucémicos mediante una medición posterior adicional y la insulina correctiva; el paciente debe continuar realizando mediciones previas y posteriores a las comidas; y como el paciente tiene sus hábitos alimenticios variados, obtener y registrar datos sobre tipos de comida especiales de modo que se pueda mejorar además el tratamiento. Además, se puede proporcionar el cumplimiento, para los propósitos de esta simulación, en términos de una proporción de cumplimiento, en el que la proporción de cumplimiento es igual al número de veces que se registra en realidad un acontecimiento dividido por el número de veces que se ha de registrar un acontecimiento.

Por ejemplo, un paciente tiene un registro de 103 mediciones preprandiales en el desayuno, y el periodo de tiempo durante el que se realizaron las mediciones es de 120 días. Por lo tanto, la proporción de cumplimiento para el desayuno es 103/120, o 0,86. Entonces, como ejemplo, en este caso se cumple un cumplimiento de ayuno en el desayuno requerido de 0,8 o mejor. El profesional sanitario revisa este informe y el tratamiento en la etapa 144, y si no hay cambios, lo da por válido. El procedimiento 100, ahora en el punto de entrada 4, genera el informe y la recomendación del tratamiento en 160 como una receta, y actualiza electrónicamente el registro del paciente. Las implementaciones del sistema específicas de acuerdo con la presente invención y usos de las mismas se proporcionan en lo sucesivo con referencia hecha a las FIGS. 2-9. Cómo el sistema y procedimiento de la presente invención responden a un acontecimiento se analizan en lo sucesivo.

Solicitar respuestas de programa informático por medio de un acontecimiento

Como se menciona previamente antes un acontecimiento es una unidad de información generada por un componente que se puede usar por otro componente del sistema. La hora del acontecimiento es intrínseca a una unidad de acontecimientos, un descriptor que caracteriza un acontecimiento, una pauta de acción del acontecimiento y un valor del acontecimiento. Otros detalles se proporcionan posteriormente. La activación de un acontecimiento en el sistema tiene que ver con los valores de especificación para los elementos que conforman el acontecimiento. Un acontecimiento en un modo de realización puede ser: (i) una entrada de información, (ii) información sobre la actividad, (iii) dispositivo de solicitud para hacer algo, (iv) informar a un paciente para que haga una tarea, (v) informar a un paciente de un estado fisiológico potencial, etc. La estructura del acontecimiento en un modo de realización tiene los siguientes campos: hora del acontecimiento absoluta; tipo de acontecimiento; duración/hora de acción/hora de actividad del acontecimiento; en relación con el padre, el tiempo de inicio del acontecimiento; cantidad, (intensidad) del acontecimiento; y cadena de avisos. La hora del acontecimiento absoluta proporciona cuándo se debe producir un acontecimiento y tiene los siguientes valores: predeterminada, determinada por un algoritmo o desencadenada de forma asíncrona. La hora del acontecimiento se proporciona como una hora absoluta que, en general, actúa como referencia absoluta. En casos especiales, la hora del acontecimiento absoluta está vinculada a la hora absoluta de otro acontecimiento. Se usa la hora UTC absoluta como la "hora de referencia" a la que se asocia el acontecimiento. La hora de referencia es esencial en la correlación de otros acontecimientos. Y una determinación del tiempo única no es trivial considerando las múltiples zonas horarias y el ahorro de luz natural. Es pertinente una distinción entre la hora local y la hora universal coordinada (UTC). Se usa la hora local para el propósito de visualización y se mapea la UTC con respecto a la hora local.

El tipo de acontecimiento describe qué acontecimiento se ha excitado y tiene valores tales como comida, ejercicio, medicamentos, medición de insulina, estado alternativo, acontecimiento correctivo y cancela un acontecimiento. La duración define la duración del efecto de una actividad, tal como la actividad de la inyección intravenosa rápida de insulina, la actividad de una comida, la duración de una actividad de ejercicio y el estado alternativo. Cualquier actividad iniciada debe estar limitada por la duración. De forma predeterminada, una actividad tiene una duración infinita. La otra posibilidad predeterminada es que la actividad no tenga duración. Significa que su impacto fue instantáneo. Un valor distinto de cero desde 0 al infinito captura todos los casos intermedios. La hora relativa, con respecto a la hora de referencia absoluta, es que el acontecimiento se inicia a una hora absoluta ajustada con respecto a la hora relativa. Esto podría ser para una inyección intravenosa rápida relacionada con la comida activada en el momento en el que es igual a una hora del acontecimiento absoluta más una hora relativa, una medición en relación con el acontecimiento de comida o una medición en relación con la última medición de bG. La cantidad describe la intensidad o magnitud del acontecimiento, y puede ser para una cantidad de insulina, un tamaño de una comida y una velocidad de una comida. Finalmente, la cadena de avisos es una parte concisa, pero narrativa, de la información. En un modo de realización, este campo se genera en XML o RTF u otro lenguaje de marcado para presentar una información más detallada y descriptiva específicamente ajustada para el usuario final y el registro en la base de datos. En general, la cadena de avisos es un comentario de la actividad en curso en tareas anteriores, actuales y futuras. La utilización del uso de lenguaje con etiquetas en este campo potencia la capacidad global para proporcionar al usuario todas las herramientas potenciales para interactuar, tales como audio, gráficos visuales, enlaces estáticos y dinámicos. Los enlaces dinámicos pueden incluir barras de progreso, gráficos de barras, etc. Por ejemplo, el tiempo con respecto a la actividad se puede representar mediante la barra de progreso, la insulina distribuida a partir de la cantidad que se va a dispensar se podría mostrar como barra de progreso, etc.

Obsérvese que para caracterizar la introducción de datos de acontecimientos de la anterior manera se pueden proporcionar los siguientes programas de utilidades en el sistema: solicitar a una unidad de distribución de medicamentos (bomba de insulina) que distribuya medicamentos (insulina) con características de introducción de datos dadas; solicitar a una unidad de medición que realice una tarea de medición con características de introducción de datos dadas; recibir un conjunto de instrucciones del paciente sobre las características de introducción de datos de una actividad del acontecimiento inminente; y presentar una introducción de datos del acontecimiento a los módulos de algoritmo (es decir, componentes de programa informático del sistema que contiene el algoritmo de control glucémico) y/o generar un acontecimiento de salida de datos. El algoritmo de control glucémico se usa para realizar recomendaciones de insulina en base a los datos de sensor subcutáneo obtenidos, el perfil basal predefinido del sujeto y las introducciones de datos por el usuario para mantener los niveles de glucosa del sujeto en un intervalo objetivo. Presentar la programación específica del protocolo al (i) dispositivo (ii) algoritmo y (iii) usuario para realizar tareas/acontecimientos. Almacenar la introducción de características y recuperar la introducción de características de la base de datos. Cada uno de los programas de utilidades mencionados anteriormente se explica además usando ejemplos de cómo funciona el sistema y el programa informático de la presente invención.

Solicitar a una unidad de distribución de medicamentos que distribuya medicamentos con características de introducción de datos dadas

En este modo de realización, el dispositivo de medición/obtención de datos del paciente 48 (FIG. 2) es una unidad de administración de medicamentos, por ejemplo, una bomba de insulina programable, que funciona automáticamente para el tratamiento recomendado del sistema como se asigna como receta por el profesional sanitario al final de la etapa 160 (FIG. 4) y se carga mediante el ordenador cliente 14. El acontecimiento por sí mismo se genera de una de muchas formas: (i) algoritmo, (ii) usuario, (iii) vigilancia (herramientas de terceras partes), (iv) protección en caso de fallo, (v) acontecimientos desencadenados por la base de datos, y (vi) en base a un protocolo. Las características necesitan ser únicas y necesitarán cubrir una duración de tiempo conocido o desconocido antes de que se produzca la próxima comunicación. El horario de la medicación es fundamental para el tratamiento de la diabetes (se mantiene preferentemente el horario de todos los acontecimientos en una hora UTC con un ajuste apropiado para la hora local). El tipo de acontecimiento explica el contexto del acontecimiento y/o describe el acontecimiento desencadenado (por ejemplo, inyección intravenosa rápida para la comida, inyección intravenosa rápida solicitada, perfil de inyección intravenosa rápida para la comida). Cualquier actividad iniciada está limitada en general por la duración finita. Se entiende que la duración cubre la duración real del acontecimiento ejecutado, ya que distribuir una inyección intravenosa rápida solicitada requiere físicamente un tiempo finito para la administración y esta duración puede ser pertinente para el algoritmo que se va a considerar cuando se decide la próxima solicitud de inyección intravenosa rápida o se puede capturar la duración de la insulina para que sea la duración de la actividad de la insulina en el cuerpo del paciente. La hora relativa permite escalonar el acontecimiento con respecto a un punto de referencia. Por ejemplo, si la hora de referencia es la hora de la comida, entonces se utiliza la hora relativa para tener una dosis previa a la comida, por ejemplo, especificando la hora negativa en minutos. Una secuencia de dichos números extiende además la pauta de dosis única a una secuencia distribuida de dosis en relación con la hora de la comida. Cantidad que se puede referir a la intensidad de una actividad o representa la cantidad. Por ejemplo, en este caso particular, la cantidad de insulina que se va a distribuir. Como la duración, también puede ser una secuencia de números. El número de elementos en la secuencia normalmente coincidirá con el del número de elementos en la hora relativa. La cadena de avisos presenta la información en (i) formato gráfico, (ii) de audio. Adicionalmente, la información, si está almacenada, presenta un registro de la actividad.

Solicitar a una unidad de medición que realice una tarea de medición con características de introducción de datos dadas

Las mediciones son necesarias para el control manual o para un control de retroalimentación automatizado para lograr un buen rendimiento. Entonces, desde el punto de vista funcional, las mediciones se generalizan como otra unidad de acontecimientos. Por supuesto, las mediciones tienen consideraciones, tales como el coste asociado, la limitación de cuántas mediciones se pueden realizar en un sentido realista, cómo se usan las mediciones dicta la secuencia de las mediciones, las mediciones también se pueden relacionar con el protocolo para realizar una tarea, se necesitan mediciones para mejorar el rendimiento, valor de complementos de aviso de medición asistiendo al usuario, el profesional sanitario (PS) (por ejemplo, médico, RN, LPN o paramédico/EMT), el equipo de apoyo en emergencias con tiempo ideal para medir el mejor tiempo mínimo para medir y mantener la seguridad. Las diversas posibilidades se cubren por las características del acontecimiento mencionadas anteriormente y se abordan de nuevo para la medición de bG. El horario de medición es fundamental para proporcionar un buen tratamiento. La medición, cuando se realiza, se captura preferentemente en la UTC y se envía al algoritmo y/o base de datos. Adicionalmente, el aviso de medición se presenta en hora local. Por ejemplo, en un modo de realización, el dispositivo de medición/obtención de datos del paciente 48 se programa como se describe anteriormente para decirle al paciente en términos absolutos cuándo se debe realizar la medición en hora local de acuerdo con la salida de datos como receta por el sistema. Para esta utilidad, el tipo de acontecimiento explica el contexto del acontecimiento y/o describe el acontecimiento desencadenado. Por ejemplo, la medición del punto de bG representa un medidor de bG usado para la medición, una extracción de sangre representará una muestra de sangre para análisis, tal como la obtención de la medición de bG, la concentración de insulina en plasma o la medición de A1C. Cualquier actividad iniciada está limitada en general por la duración. Se entiende que la duración cubre la duración real del acontecimiento ejecutado, ya que la medición requiere físicamente un tiempo finito para determinar la concentración de glucosa y esta duración puede ser pertinente para el algoritmo que se va a considerar, tal como que en una medición continua se pueden tener retardos de medición, de retardos pequeños a tanto como 30 min. Existen casos en los que la duración puede no ser significativa y, en dicho caso, la entrada se deja en blanco. Se puede hacer que la hora relativa para la medición cubra muchas situaciones de los casos de uso y puede ser contextual. La hora relativa puede actuar como una cuenta atrás o tiempo restante para realizar la medición. Puede representar el tiempo transcurrido desde la última medida. Puede representar el tiempo desde el tiempo de medición deseado. Puede representar una secuencia de tiempo para los requerimientos de medición basados en protocolos o acontecimientos que pueden consistir en una secuencia de mediciones en duraciones de tiempo especificado. Cantidad que se puede referir a la intensidad de una actividad o representa la cantidad. Por ejemplo, en este caso particular, la cantidad representa el valor de medición. Si se le proporciona al dispositivo 48 una unidad de medición de bG, el dispositivo puede presentar la medición, y en caso de que se especifique el tiempo de las mediciones y aún no se hayan realizado las mediciones, se puede proporcionar la lógica para controlar las futuras entradas y/o la entrada que falta. Por último, la cadena de avisos puede presentar la información tanto en formato gráfico como de audio. Adicionalmente, toda la información se almacena ahora como un registro de la actividad.

Recibir un conjunto de instrucciones del paciente sobre las características de introducción de datos de una actividad del acontecimiento inminente

En general los acontecimientos se deben caracterizar para obtener un mejor rendimiento. Actualmente, solo se utilizan las comidas, por ejemplo, recuento de carbohidratos. En dicho caso, el campo cantidad del acontecimiento captura la concentración neta de la comida. Sin embargo, no se aborda el rasgo característico más completo, tal como su velocidad o su índice glucémico. El campo duración del acontecimiento se puede usar para capturar uno de los aspectos de la velocidad de la comida. El acontecimiento de comida se puede describir además como rápido, medio o lento para capturar de nuevo la velocidad de la comida. Otro ejemplo es el ejercicio, donde la intensidad y duración pueden ayudar a capturar el nivel de actividad. Estos y otros ejemplos pueden usar un algoritmo del procedimiento 100 para ajustar cómo la insulina base se debe ajustar para proporcionar un tratamiento recomendado. El campo hora relativa en caso de ejercicio permite programar previamente un acontecimiento que el algoritmo del procedimiento 100 puede usar para ajustar la insulina con antelación para que coincida con el próximo acontecimiento. Esto es muy útil para potenciar el rendimiento de un tratamiento, puesto que existen retardos en el sistema y en la respuesta.

Se necesita el horario de ingestión de una comida, de la actividad física, tal como como el ejercicio, o de estar en un estado alternativo, tal como el estrés, para hacer un ajuste del tratamiento. La identificación de dicha actividad podría ser manual y, en este caso, el acontecimiento se desencadena por una entrada manual. Se mantiene preferentemente el horario de todos los acontecimientos en una hora UTC con un ajuste apropiado para la hora local. El tipo de acontecimiento explica el contexto del acontecimiento y/o describe el acontecimiento desencadenado. Por ejemplo, la comida se puede describir como índice glucémico alto o bajo, se puede caracterizar por la composición tal como grasa, proteína, carbohidrato, fibra o por descriptores tales como comida rápida, media o lenta. Cualquier actividad iniciada está limitada en general por la duración finita. Se entiende que la duración cubre la duración real del acontecimiento desencadenado. Por ejemplo, conocer la duración de la actividad de una comida es pertinente para las comidas de absorción lenta. Conocer la duración ayuda en la determinación de la distribución de insulina. De forma similar, otro acontecimiento que caracteriza la selección potencia el conocimiento de la carga fisiológica anticipada que se usa por el algoritmo para abordar las necesidades de tratamiento.

El campo hora relativa permite escalonar el acontecimiento con respecto a un punto de referencia. En los estudios clínicos, está claro que el conocimiento avanzado puede potenciar además el rendimiento del controlador. En el tratamiento con insulina basado en la acción anticipada, la insulina se puede reducir o dosificar previamente. En general, para un ejercicio anticipado, la insulina basal se reduce y, además, el algoritmo aumentará un acontecimiento de ingestión de carbohidratos para mantener la glucosa en el intervalo normoglucémico. En las comidas de absorción rápida, la dosificación previa también ayuda a frenar el rápido aumento de glucosa. El campo cantidad se puede referir a la intensidad de una actividad o bien a la cantidad. Por ejemplo, en caso de ejercicio agotador, se referirá a la intensidad del acontecimiento de ejercicio y, en caso de comida, se puede describir por la cantidad de carbohidratos. Como la duración, también puede ser una secuencia de números. El número de elementos en la secuencia normalmente coincidirá con el del número de elementos en la hora relativa. La cadena de avisos presenta la información en (i) formato gráfico, (ii) de audio. Una cadena de avisos, en el caso del ejercicio, es aconsejar al paciente que consuma carbohidratos de acción rápida para compensar la carga física y, por tanto, la necesidad de carbohidratos. Adicionalmente, la información anterior del acontecimiento, si está almacenada, presenta un registro de la actividad.

Presentar una introducción de datos del acontecimiento a los módulos de algoritmo y generar un acontecimiento de salida de datos

Un algoritmo es un conjunto de instrucciones para determinar una acción o un resultado. El algoritmo es un receptor de acontecimientos, es un generador de acontecimientos internos y es un creador de acontecimientos externos (datos de salida). El algoritmo por sí mismo está estructurado modularmente para permitir el tratamiento de problemas complejos de manera estructurada. La estructura se centra en desglosar el problema en unidades funcionales que se especializan en la tarea dada. La modularidad permite además incluir o excluir efectos dependiendo de la necesidad del problema. El comportamiento final se filtra a través de heurística adicional. Entonces, en un nivel más alto, cada módulo se puede ver como una superposición de efectos. Pero en el núcleo, cómo se gestiona cada uno de los módulos no está restringido. maPor tanto, la funcionalidad modular de alto nivel es como sigue: control y mantenimiento; monitorización e información sobre el estado; gestión de acontecimientos importantes; acciones de control del núcleo (fundamentales para proporcionar un control glucémico); y acciones correctivas.

Control y mantenimiento

Los módulos de control y mantenimiento son como sigue: inicialización/preparación; gestión de ciclos perdidos; mapeo de acontecimientos; depósitos de insulina; anulación de componentes; base de datos; e implementar protocolo. La inicialización/preparación es un vector de estado que controla la información anterior, actual y futura. La gestión de ciclos perdidos gestiona el reinicio del procedimiento 100 o las llamadas del algoritmo que se omitieron por cualquier motivo como protección en caso de fallo. El mapeo de acontecimientos mapea el conjunto de acontecimientos externos con respecto al conjunto de acontecimientos internos. Los depósitos de insulina controlan la recomendación de insulina de diversos módulos como componentes para llenar y vaciar los depósitos. La anulación de componentes se explica como sigue. En general, cuando una solución, como la actual, en la que la fisiología, a pesar de las introducciones de datos y salidas de datos, es un efecto neto de diversos componentes cuando se resuelve problema (i) como componentes individuales o (ii) efectos modulares agrupados, la etapa de anulación permite la eliminación de un efecto, no se requiere durante la consideración del componente individual o efecto modular agrupado. Por tanto, por ejemplo, la anulación de la insulina está anulando cualquier componente de la insulina que proceda de los términos de prealimentación de la acción de control de la administración de insulina final. El control interno de inyecciones intravenosas rápidas proporciona inyecciones intravenosas rápidas de prealimentación que resultan de un acontecimiento de comida. El control interno de inyecciones intravenosas rápidas permite (i) la creación de acontecimientos internos y (ii) la agrupación de acontecimientos internos. De este modo, el control de los elementos del tratamiento se generaliza y permite la flexibilidad de añadir o eliminar un efecto dependiendo de las necesidades cambiantes y la disponibilidad de la información nueva. La base de datos proporciona la recuperación y almacenamiento de datos, e información de registro. Implementar protocolo es un formato de protocolo diseñado según la estructura del acontecimiento genérica para permitir la creación dinámica de una actividad de protocolo como se desee por el personal sanitario. Un aspecto del protocolo es respaldar el cumplimiento para generar información mínima para analizar y generar información específica del paciente.

Monitorización e información sobre el estado

Los módulos para monitorizar e informar sobre el estado son como sigue: actualización de glucosa, glucosa desactualizada, inyección intravenosa rápida automática, aviso de comidas, aviso de protocolo, seguridad ante fallos y gestores de acontecimientos importantes. La actualización de glucosa verifica la disponibilidad de nuevos valores de medición de glucosa relacionados con las necesidades de cumplimiento y medición y genera información para el usuario. La glucosa desactualizada informa al usuario de si existe una necesidad de obtener un valor de glucosa reciente, relacionado de nuevo con las necesidades de cumplimiento y medición. También se genera información para el usuario. La inyección intravenosa rápida automática tiene en cuenta cualquier discrepancia en la insulina por medio de solicitudes de inyección intravenosa rápida automática (actividad interna). El aviso de comidas informa al usuario para que comience a comer. El problema de cumplimiento que cubre la ingesta de carbohidratos, y se puede extender a otra monitorización e información. El aviso de protocolo informa al usuario de la actividad próxima o pendiente generando acontecimientos internos. El sistema de seguridad informa sistemáticamente a un respondedor (por ejemplo, un servicio padre o de vigilancia) de que el usuario está apagando el dispositivo o el sistema y configura alarmas para crear ventanas de tiempo durante las que, si el dispositivo y/o sistema no está activo o si no se realiza una llamada para ignorar las alarmas, entonces, se proporciona como ayuda un envío de emergencia o formularios alternativos para comunicarse. Los gestores de acontecimientos importantes son módulos para gestionar acontecimientos importantes, tales como ejercicio preparatorio, ejercicio, inyección intravenosa rápida solicitada y compensador de comidas. El ejercicio preparatorio revisa el requerimiento basal con anticipación al controlador de ejercicio e informa al controlador al comienzo del ejercicio específico. El ejercicio mantiene el punto fijo de glucosa elevado durante la duración del ejercicio y, entonces, regresa a su punto fijo de glucosa. La inyección intravenosa rápida solicitada es una petición para una inyección intravenosa rápida de insulina adicional (control del usuario) y permite una solicitud asíncrona. El compensador de comidas informa al controlador de la ingestión de carbohidratos. El estado alternativo/acontecimientos desencadenados cubren el estado alternativo y los acontecimientos desencadenados.

Acciones de control del núcleo

Los módulos de acciones de control del núcleo forman las acciones de control del núcleo fundamentales para proporcionar un control glucémico y son como sigue: procesar datos del sensor, punto fijo de insulina, predicción de glucosa, módulo de recomendación de insulina, compensador de ejercicio, ingestión de carbohidratos de acción rápida, compensador de comidas, selección del modelo, determinación/actualización de los parámetros del modelo, caracterización del paciente, gestión de discrepancias, insulina administrada final e insulina recomendada final. Procesar datos del sensor determina un valor de glucosa a partir de valores de glucosa medidos disponibles, por ejemplo, valores de líquido intersticial (isf) obtenidos a través de la unidad de sensor y/o valores de glucosa en sangre (bG) obtenidos a través de un medidor externo. El punto fijo de insulina es la tasa de infusión de insulina usada para mantener la glucosa basal objetivo (es decir, el valor de glucosa logrado para la tasa de insulina basal dada). La predicción de glucosa predice el valor de glucosa para ciclos de control usando los valores de medición de glucosa anteriores, las mediciones de insulina anteriores, acontecimientos anteriores y futuros acontecimientos programados. Un ciclo perdido es cuando el algoritmo no se llama durante un ciclo de control. Obsérvese que la glucosa se puede medir como glucosa o la glucosa predicha, como se determina por el contexto en el que se analiza. La glucosa medida es el valor de glucosa obtenido de un sensor de glucosa. La glucosa predicha es el futuro valor de glucosa determinado a partir de un valor de glucosa conocido usando un modelo. La glucosa objetivo del tratamiento es el valor de glucosa que el usuario desea logar. El punto fijo de glucosa objetivo/glucosa es el valor de glucosa que el controlador intenta lograr de forma asintótica a través de la retroalimentación. La acción de control basal computa la dosis de insulina para mantener la glucosa basal. La determinación se basa en modelos y/o conjuntos de reglas.

El compensador de ejercicio gestiona un nivel de actividad física incrementado. La determinación se basa en modelos y/o conjuntos de reglas. La ingestión de carbohidratos de acción rápida gestiona la ingestión de carbohidratos de acción rápida para compensar una caída de glucosa esperada. La determinación se basa en modelos y/o conjuntos de reglas. El compensador de comidas computa la distribución de las inyecciones intravenosas rápidas de insulina para un acontecimiento de comida. La determinación se basa en modelos y/o conjuntos de reglas. La implementación basal de bucle abierto implementa insulina basal durante el controlador de bucle abierto. La determinación se basa en conjuntos de reglas. La selección del modelo es la determinación de un modelo apropiado que aborde de la mejor manera las necesidades del paciente, tal como parte del procedimiento 100 descrito anteriormente con respecto a la FIG. 4. Las reglas se basan en la selección del estilo de vida, acontecimientos anteriores usados, futuros acontecimientos y protocolo y/o simplemente se basan en la selección del profesional sanitario. La determinación/actualización de los parámetros del modelo determina los parámetros para el modelo seleccionado. La determinación usa datos anteriores, datos obtenidos por el dispositivo, configuraciones de determinación de los parámetros. La caracterización del paciente es cuando se evalúa la selección del parámetro específico del paciente o el uso del modelo basado en la población. El modelo y parámetro determinados pasan por una serie de comprobaciones y, si los resultados cumplen con y mantienen determinadas expectativas conocidas, entonces, se seleccionan los parámetros determinados, de lo contrario se utiliza dicho conjunto de parámetros basados en la población subóptimos para la determinación del tratamiento, controlando la glucosa. La determinación/actualización de los parámetros del tratamiento también es como previamente se describe anteriormente con respecto al procedimiento 100 de la FIG. 4. La gestión de discrepancias gestiona los depósitos de insulina cuando se identifica la discrepancia entre la insulina solicitada frente a la insulina administrada. La insulina administrada final es la cantidad de insulina distribuida para el ciclo. La insulina recomendada final es la dosis de insulina que se computa por el algoritmo y se envía al profesional sanitario como una recomendación.

Acciones correctivas

Las acciones correctivas son módulos que se pueden usar para tomar acciones correctivas que son como sigue: rectificación de carbohidratos, intervención de alto contenido de glucosa, intervención de bajo contenido de glucosa y zona de glucosa de la comida. La rectificación de carbohidratos revisa el acontecimiento de comida introducido previamente (valor de carbohidratos) y la administración de insulina se corrige en consecuencia. La intervención de alto contenido de glucosa corrige el alto nivel de glucosa por medio de la administración de insulina. La intervención de bajo contenido de glucosa corrige el nivel de bajo contenido de glucosa por medio de la ingestión de carbohidratos de acción rápida. La zona de glucosa de la comida define el objetivo de glucosa como una banda, en lugar de como una línea. En otros modos de realización, se pueden usar otras acciones correctivas adecuadas.

Presentar la programación específica del protocolo al (i) dispositivo (ii) algoritmo y (iii) usuario para realizar tareas/acontecimientos

El protocolo es una ejecución planificada de una secuencia de acontecimientos. La adhesión al plan permite (i) un tratamiento mejorado (ii) poder usar los datos obtenidos para un análisis particular y determinar una acción médica o (iii) un caso de uso general donde se planifica un estilo de vida, tal como un plan de alimentación, plan de ejercicio, horario de las comidas, composición de la comida. Esto es pertinente para respaldar al personal sanitario solo con datos, pero datos obtenidos con el horario correcto y acontecimientos asociados, tales como una comida con un contenido específico de grasas, proteínas y carbohidratos. Entonces, un protocolo es una secuencia específica de unidades de acontecimientos compuesta por mediciones de bG, solicitudes de inyección intravenosa rápida, ingestión de comida y ejercicio. Los acontecimientos se pueden desencadenar en muchos modos, tales como los dispositivos de mano que se programan, una simple descripción basada en papel que el paciente sigue, un servicio automatizado, tal como un asesor de cumplimiento que asiste al paciente.

Almacenar la introducción de características y recuperar la introducción de características de la base de datos

La base de datos es la unidad de almacenamiento de información central. La base de datos se usa para almacenar y recuperar acontecimientos y configuraciones específicas del usuario. Los acontecimientos almacenados cubren acontecimientos anteriores, presentes y programados futuros. La base de datos se usa en términos de almacenamiento de información sobre acontecimientos como registro de la actividad actual en curso y anterior, se usa para recuperar acontecimientos anteriores y futuros y se usa para desencadenar acontecimientos programados. Ahora se proporcionan en lo sucesivo implementaciones del sistema, procedimiento y módulos de programa informático descritos anteriormente para adicionalmente en el entendimiento de la invención.

Ejemplos de implementación específica

El aparato y metodología descritos anteriormente se unifican en los siguientes modos de realización ilustrados, que potencian la capacidad del personal sanitario para obtener, analizar y determinar el tratamiento para abordar una enfermedad crónica, tal como la diabetes. En un primer modo de realización ilustrado que emplea la metodología del DTPS, se divulga un programa banco de pruebas para páncreas automatizado (APTS). ApTS es un programa informático que se usa para controlar al sujeto diabético en un entorno clínico. En un segundo modo de realización ilustrado que también emplea la metodología del DTPS, se divulga un programa paquete de pruebas con algoritmo de control para páncreas automatizado (APCATS 900). APCATS 900 es un programa informático que analiza a un sujeto diabético en un entorno emulado que se ejecuta, por ejemplo, en el ordenador cliente 14 (FIG. 2). Con referencia a la FIG. 5, el programa APTS se analiza en primer lugar, seguido de un análisis sobre el programa APCATS 900 después de esto en secciones posteriores.

Programa banco de pruebas para páncreas automatizado (APTS)

Con referencia a la FIG. 5, el programa APTS 500 se ejecuta en un ordenador convencional (por ejemplo, ordenador portátil, asistente digital personal (PDA), teléfono inteligente, etc.) y proporciona dos componentes de programa informático independientes: un programa informático para páncreas automatizado (APS) 502 y una aplicación de comunicación de programa informático para páncreas automatizado (APSCOM) 504. Como se explicará en una sección posterior, el APS 502 realiza llamadas periódicas a un algoritmo de Shell (ALGOSHELL) 506 incluido en cuanto a las recomendaciones de insulina e interacción con APSCOM 504. En lo sucesivo se proporciona un análisis sobre el ALGOSHELL 506 en una sección posterior. La APSCOM 504 es responsable de obtener información de una unidad portátil (PU) 508, interactuar con el APS 502 y almacenar y recuperar información de una base de datos, tal como la base de datos 24 (FIG. 2). En un modo de realización, la PU 508 es el dispositivo 48 (FIG. 2), y en otro modo de realización es un sensor que mide la concentración de glucosa, tal como, por ejemplo, un monitor continuo de glucosa subcutáneo (SCGM), que es un dispositivo basado en microdiálisis desarrollado por Roche Diagnostics Corporation para realizar mediciones de glucosa frecuentes. Todavía en otro modo de realización, la unidad portátil 508 es una bomba de insulina o sistema de bomba de insulina, tal como, por ejemplo, el sistema de bomba de insulina Accu-Chek® Spirit de Roche Diagnostics. En el modo de realización del sistema de bomba de insulina, la APSCOM 504 se puede comunicar con el programa informático proporcionado en una PDA que se proporciona con el sistema de bomba de insulina, o si se ejecuta el APTS en la misma PDA, con el programa informático de control de bomba de insulina.

También se proporciona una llamada al módulo de controlador de ALGO 510 que determina la pauta de administración de insulina y comunica las dosis a APS 502 a través de ALGOSHELL 506. Por pauta, aquí se entiende un par de tiempo y valor. El ALGOSHELL 506 realiza algunas de las funcionalidades del sistema estándar, tales como el control del estado, el filtrado de llamadas de ALGO, la conversión de unidades y la determinación de la cantidad que se ha de distribuir. El APS 502 es responsable de llamar a ALGOSHELL 506 en un intervalo periódico de tiempo denominado en el presente documento ciclo de control. El APS 502 también interactúa periódicamente con APSCOM 504. En un modo de realización, la APSCOM 504 usa la tecnología Microsoft© COM para comunicarse con programas tales como APS 502 y la base de datos 24 (FIG. 2), que, en un modo de realización, se puede implementar como una base de datos de Microsoft© Access. En otros modos de realización, se pueden usar otros marcos de comunicación y aplicaciones de base de datos para implementar la presente invención, tales como .net framework, Unix, Oracle, SQL, Java y similares. El programa APTS 500 también proporciona una interfaz de uso 512, que el APS 502 usa para presentar datos y recibir información sobre acontecimientos del PS y/o del paciente.

Flujo de trabajo del sistema

Esta sección ilustra el funcionamiento y el flujo de trabajo del sistema, y las diversas secuencias de llamadas APS-ALGO de alto nivel que está directamente relacionadas con el ALGO 510 controlador. La secuencia de acontecimientos en el sistema por un periodo del ciclo de control Te corresponde a las letras en círculos A-J en la FIG.

5. El APS 502 controla el sistema de manera mecánica, y algunos de los descriptores de tiempo clave se detallan en la FIG. 5. En el acontecimiento A (tiempo-T^a), el APS 502 llama a APSCOM 504 y adquiere el nuevo conjunto de datos del sensor y los datos para la insulina neta distribuida. El tiempo con respecto a un límite de control ahora se fija en cero, y en la secuencia de acontecimientos B, el APS 502 llama al ALGOSHELL 506. El ALGOSHELL 506, entonces, actualiza la información sobre el estado, realiza la conversión de unidades, comprueba el modo y llama al ALGO 510 para una recomendación de insulina. El ALGO 510 devuelve la recomendación al ALGOSHELL 506. El ALGOSHELL 506 realiza la conversión, entonces, actualiza el estado y regresa al APS 502. Después de completar la secuencia de acontecimientos B, el ALGOSHELL 506 devuelve una recomendación al APS 502 que es la secuencia de acontecimientos C. Esto se denomina una llamada SYNC-1.

Después de completar la secuencia de acontecimientos C, en la secuencia de acontecimientos D, el APS 502 abre una ventana de recomendación 514 en la interfaz de usuario 512 y espera a que el usuario acepte o cancele la recomendación, por medio del uso de un dispositivo de introducción de datos, tal como el dispositivo 40 (fig. 2). El APS 502 esperará la introducción de datos hasta que expire el tiempo de la ventana de recomendación. Después de completar la secuencia de acontecimientos D, la ventana de recomendación regresa al APS 502 para la secuencia de acontecimientos E. Si el usuario confirmó la recomendación, completando, por tanto, la secuencia de acontecimientos E, entonces para la secuencia de acontecimientos F, el APS 502 abre una ventana de confirmación 516 en la interfaz de usuario 512 y espera a que el usuario acepte o cancele la confirmación por medio del dispositivo de introducción de datos (por ejemplo, el dispositivo 40). El a Ps 502 esperará la introducción de datos hasta que expire el tiempo de la ventana de confirmación. Después de completar la secuencia de acontecimientos F, para la secuencia de acontecimientos G, la ventana de confirmación regresa al APS 502. Entonces, para la secuencia de acontecimientos H, el APS 502 llama al ALGOSHELL 506 con una cantidad de dosificación que (a) se confirma por el usuario, (b) se fija en cero por el usuario o bien (c), en el caso de un tiempo de expiración, una cantidad que cumple con un requerimiento umbral, de lo contrario sería 0. La segunda llamada de ALGO se llama una llamada SYNC-2. Obsérvese el requerimiento umbral es una dosis de insulina recomendada acordada que se administra al sujeto, a menos que se rechace por el profesional sanitario. Después de completar la secuencia de acontecimientos H, el ALGOSHELL 506 devuelve la cantidad de solicitud final al APS 502 para la secuencia de acontecimientos I, y, entonces, el APS 502 emite una solicitud de inyección intravenosa rápida a APSCOM 504 para la secuencia de acontecimientos J. Esto finaliza el periodo del ciclo de control.

ALGO

Esta sección aclara además los funcionamientos clave del ALGO 510. Es crítico para el tratamiento que las dosis se proporcionen de manera confiable y oportuna. En las siguientes secciones, se abordan los siguientes aspectos del ALGO 510: aspectos sobre el horario —cómo ALGO 510 basado en índices determina el tiempo real transcurrido—; duración de la memoria — longitud del historial anterior (memoria del sistema) requerida para determinar una nueva recomendación—; ciclos perdidos —cómo el ALGO 510 gestiona las llamadas perdidas—; modos de funcionamiento; y llamadas a un módulo de algoritmo empírico (EA) 518 proporcionado en el ALGO 510. El EA 518 es una colección de estrategias de tratamiento intensivo en base a reglas para recomendar la dosis de insulina que requiere y/o proporciona una serie de módulos funcionales 56 (FIG. 3). La recomendación de dosificación de insulina se basa en la información más reciente sobre la glucosa e información sobre acontecimientos, tal como comidas, ejercicio, intervención, etc. El tratamiento intensivo es una forma de tratamiento para la diabetes de tipo 1 en el que el objeto principal es mantener los niveles de glucosa en sangre lo más cerca posible del intervalo normal. El tratamiento consiste en tres o más inyecciones de insulina al día o el uso de una bomba de insulina; cuatro o más pruebas sobre la glucosa en sangre al día; ajuste de insulina, ingesta de alimentos y niveles de actividad en base a los resultados de las pruebas sobre la glucosa en sangre; asesoramiento dietético; y control por un equipo de diabetes. El EA 518 extiende este principio monitorizando continuamente la glucosa e implementando reglas de tratamiento intensivo en intervalos regulares frecuentes. La recomendación de dosis de insulina se evalúa usando las mediciones de glucosa más recientes, información sobre la administración de insulina anterior e información sobre acontecimientos, tal como comidas, ejercicio, intervención, etc. En un modo de realización, dichas actualizaciones con respecto al EA 518 se realizan convenientemente proporcionando una arquitectura abierta que permite reemplazar/actualizar un EA 518 existente con un algoritmo empírico revisado. Uno de dichos procedimientos de arquitectura abierta adecuados que se puede implementar en la presente invención se describe en la solicitud de EE. UU. pendiente de tramitación con n.° de serie_______________titulada SYSTEM AND METHOD TO PROVIDE AN OPEN ARCHITECTURE FOR SEMI- OR FULLY-CLOSED LOOP THERAPY DELIVERY SYSTEMS, y que tiene el n.° de expediente del apoderado ROP0015PA/37554.21/ WP24356US, que está asignada al cesionario de la presente divulgación, y cuya divulgación se incorpora en el presente documento por referencia.

Como se usa en el presente documento para definir porciones del EA 518 y otros módulos del APTS 500, los símbolos enumerados en la tabla 2 tienen la siguiente nomenclatura.

Tabla 2 - Nomenclatura

Aspectos sobre el horario

Como se menciona, APTS es un sistema en tiempo real donde los horarios son un aspecto clave en la dosificación. El EA 518 usa un compensador digital independiente del tiempo real que determina la cantidad de control apropiada. El EA 518 está estructurado de tal manera que no tenga ningún sentido real del horario, pero usa el horario que existe en los índices de matrices variables. En otras palabras, las acciones del EA 518, en un sentido, están basadas en un índice, y la noción de tiempo se vuelve implícita mediante la selección de un periodo del ciclo de control T^c. Por ejemplo, la farmacodinámica de la insulina se define como una matriz unidimensional de insulina restante Ir [i], donde el elemento iésimo indica indirectamente la insulina restante en el tiempo transcurrido t = (i-1)Tc. Por tanto, existe una correspondencia entre el índice iésimo y el tiempo t.

Como se muestra mediante la FIG. 20, la descripción de tiempo del controlador ALGO 510 depende no solo de la hora del día, sino también del tiempo transcurrido desde el inicio de un experimento (por ejemplo, el inicio de una

recomendación de tratamiento implementada como una receta). El término 1A representa el tiempo en que se inicia el experimento y se almacena por APS 502. El tiempo se convierte en minutos y representa el tiempo en minutos desde la medianoche. El término ta es la hora real del día en minutos desde la medianoche. El término t es el tiempo transcurrido en relación con el inicio del experimento, donde la hora relativa t=0 indica el inicio del experimento. El término K=1 se refiere al primer ciclo de control. Cada ciclo posterior se incrementa en 1. El término k indica el késimo ciclo actual. Cada periodo del ciclo de control T^c tiene un par de límites de control, un tiempo de inicio ts y un tiempo de finalización te. En cualquier hora relativa t, el ALGO 510 determina con respecto a qué periodo del ciclo de control T^c la llamada actual se establece para la hora actual T. Es crítico que el sistema de control en tiempo real implementado tenga un ligero control del tiempo. Esto significa que una llamada al ALGO 510 no se encuentra exactamente en el límite de inicio del periodo de ciclo de control T^c, sino que, más bien, dentro de cierta exactitud temporal sobre el límite de control del tiempo de inicio ts. El término T& es una desviación del tiempo desde el límite de control y es el instante en el que la petición de datos se envía y adquiere por APS 502. Por ejemplo, un valor puede representar un hora en la que la PU 508 transfiere datos obtenidos de diversos dispositivos al APS 502 por medio de APSCOM 504. El término Tv es la hora en la que el APS 502 transfiere la insulina solicitada a la PU 508. El término Ts es la duración máxima del tiempo de expiración para el que se presenta la ventana de recomendación y confirmación con respecto al límite del tiempo de inicio ts del periodo del ciclo de control T^c.

Duración de la memoria

El EA 518 usa la información anterior y la información actual para computar la recomendación de insulina para el ALGO 510. El periodo de tiempo durante el que se necesita la información depende de cuánto tiempo precisa el T¡

sistema para borrar el efecto de una introducción de datos. Si la duración de la actividad de la insulina es o minutos, entonces, como viene dada por la ecuación (4):

donde n es el número de ciclos durante los que se mantiene la información. Para cubrir el caso de ciclos perdidos, también se necesitan varios ciclos de control adicionales como memoria intermedia. En este caso, nH se define como la suma de n y el número máximo de ciclos perdidos esperados. El intervalo necesario (y suficiente) para controlar el ALGO 510 es mantener el historial durante nH ciclos.

ciclos perdidos

El ALGO 510 es responsable de procesar todas las introducciones de información nueva y de traducir la información en un tratamiento. Un ciclo perdido es un periodo del ciclo de control en el que no se llama a ALGO 510. Si el APTS 500 completo fuera perfecto, se llamaría a ALGO 510 en cada periodo del ciclo de control T^c. Sin embargo, se pueden perder las llamadas. Si se pierden ciclos, entonces, el ALGO 510 se ejecuta de forma iterativa para cada uno de los ciclos perdidos. Esto significa que, cuando ocurren ciclos perdidos, el tratamiento está pendiente hasta que se llame a ALGO 510. El ALGO 510 detecta las llamadas perdidas y recorre cada uno de los ciclos perdidos antes de ejecutar la llamada actual. Esto garantiza que los acontecimientos no se pierdan ni se dupliquen y se aborden de forma secuencial. Los ciclos perdidos se pueden producir por diversos motivos. La sincronización es exacta siempre que la información enviada al ALGO 510 no tenga discrepancias. Al gestionar esta situación, el ALGO 510 determina en primer lugar si se perdió una llamada. Si no se encuentra una llamada perdida, entonces, el ALGO 510 ejecuta los diversos módulos de EA 518. Cuando el ALGO 510 detecta llamadas perdidas, el ALGO 510 ejecuta en primer lugar todas las llamadas perdidas antes de evaluar la llamada actual.

Modos de funcionamiento

Los modos de funcionamiento admitidos por ALGO 510 son control puro y observación controlada. Haciendo referencia a la FIG. 6, el modo de control puro 600 de funcionamiento para el eA 518 es un sistema de bucle cerrado que usa mediciones de glucosa para proporcionar una acción de control apropiada. La tarea del ALGO 510 es mantener la glucosa a un nivel de glucosa objetivo predeterminado 601. Durante la inicialización del controlador o cuando se perturba al sujeto, se espera que la glucosa se desvíe del nivel de glucosa objetivo 601. El control puro usa las mediciones de glucosa y la información sobre la insulina administrada para "entender" el estado del sujeto. En la parte inferior derecha de la FIG. 6, un bloque del sujeto 602 se conecta a un sensor de glucosa 604 y una bomba de insulina 606. Estos dispositivos están indirectamente en contacto con APS 502 por medio del enlace de RF 608 de la unidad portátil 502 (FIG. 5) que se muestra en líneas discontinuas. Una línea discontinua 610 que se origina a partir del bloque de acontecimientos 612 indica la ocurrencia de los acontecimientos conocidos. La información de estos acontecimientos puede estar disponible para el ALGO 510. Un gestor de acontecimientos 614 proporciona un mapeo apropiado entre descripciones de acontecimientos externos con respecto a una pauta de acontecimientos internos. ALGO 510 activa los módulos apropiados para gestionar las perturbaciones conocidas, que incluyen al menos uno de un módulo de insulina de solicitud 616, un módulo de intervención de alto contenido de glucosa 618, un módulo de compensador de comidas 620, un compensador de ejercicio 622 o un módulo de compensador de bajo contenido de glucosa 624. Un predictor de glucosa 626 y un controlador basal 628 gestionan perturbaciones desconocidas y errores de modelado. La inicialización del controlador es un caso de perturbación desconocida. El controlador tiene que estabilizar los valores de glucosa iniciales cuando comienza el experimento, y, cuando el modo cambia del modo de observación controlada 700 al modo de control puro 600. En dichos casos, el rendimiento del modo de control puro 600 se depende de la disponibilidad de información de acontecimientos anteriores para llevar al sujeto sin problemas desde un cierto valor de glucosa inicial al valor de glucosa objetivo. Un bloque de control del depósito de bucle cerrado 630 determina y controla la recomendación de insulina neta. Los módulos de insulina administrada 632, el filtro de glucosa 634 y el anulador de dosis de insulina 636 se analizan en secciones posteriores que se proporcionan a continuación.

El modo de control puro 600 es una recomendación de insulina que usa mediciones de glucosa y acontecimientos de introducción de datos internos/externos para mantener el control glucémico. El profesional sanitario cierra activamente el bucle aceptando una recomendación de insulina, que cambia un conmutador 638 a este modo. Los modos de funcionamiento realizan la distinción entre una recomendación de insulina controlada por PS en bucle abierto y una recomendación de insulina determinada por ALGO en bucle semicerrado. A pesar de que estos dos modos se fijan por el profesional sanitario, existen situaciones en las que el ALGO 510 se dispone por sí mismo en el modo de observación controlada 700. Esto ocurre cuando se cumplen las siguientes condiciones: condición de que no hay bG que se produce en la falta de disponibilidad de la medición de glucosa debido a los retardos de medición (por ejemplo, al inicio del experimento, si es que se produce); y una medición de bG desactualizada que indicaba que el tiempo desde la última medición de glucosa disponible es más antiguo que el vencimiento de glucosa admisible. El modo de observación controlada 700 ahora se analiza en lo sucesivo con referencia hecha a la FIG. 7.

El modo de observación controlada 700 es un caso especial del modo de control puro 600 y se muestra mediante un diagrama de bloques en la FIG. 7. El tratamiento del usuario se implementa a través del uso de la tasa basal programada previamente de la bomba del sujeto y se aumenta mediante el uso de un acontecimiento de inyección intravenosa rápida solicitada. Este es un control de bucle abierto, y el tratamiento se controla manualmente por el profesional sanitario o el sujeto. Como la descripción es similar a la proporcionada para el modo de control puro 600, los elementos similares se indican con símbolos similares. Trabajando de forma sabia, las mediciones de glucosa, la administración de insulina y los acontecimientos registrados se usan principalmente por el ALGO 510 para mantener el historial y actualizar el vector de estado. Sin embargo, solo son aplicables dos módulos de acontecimientos, el módulo de inyección intravenosa rápida solicitada 616 y el módulo de intervención de alto contenido de glucosa 618. Estos módulos posibilitan al sujeto o al profesional sanitario controlar el tratamiento y administrar inyecciones intravenosas rápidas de insulina. El acontecimiento compensador de comidas 620, el compensador de ejercicio 622 y el acontecimiento de intervención de bajo contenido de glucosa 624 no se ejecutan en el modo de observación controlada 700. El control de la tasa basal 628 es una réplica del perfil de bomba programado.

Llamada del algoritmo empírico

El algoritmo empírico (EA) 518 está estructurado como un grupo de módulos. Cada módulo gestiona un aspecto de una recomendación de tratamiento. Las FIGS. 8 y 9 son un diagrama de flujo del EA 518 que muestran todos los módulos y un orden de ejecución de acuerdo con un modo de realización de la presente invención. El documento se presenta solo para propósitos ilustrativos y se puede ordenar de una serie de formas en los modos de realización ordenados. Los puntos 9X y 9Y mostrados en círculos en las FIGS. 8 y 9 son los enlaces entre las figuras. Cada módulo está estructurado como un comportamiento independiente que contribuye a la recomendación del tratamiento final. Así cada módulo se puede ver como una superposición de efectos. Las letras E-A, que codifican cada uno de los módulos, representan un grupo de modelos y, junto con sus respectivas leyendas, proporcionan información de estructuración. Los grupos de módulos y su letra asociada son: "A" —acciones de control del núcleo (fundamentales para proporcionar un control glucémico)—, "B" —control y mantenimiento (nivel superior)— ; "C" — monitorización e información sobre el estado— ; D —“acciones correctivas”— y “E” —gestión de acontecimientos importantes— . En lo sucesivo se proporciona un análisis general sobre cada uno de estos grupos de módulos.

Acciones de control del núcleo

Los módulos para las acciones de control del núcleo, fundamentales para proporcionar el control glucémico son: procesar datos del sensor 806, punto fijo de insulina 804, predicción de glucosa 838, módulo de recomendación de insulina 846, compensador de ejercicio 822, ingestión de carbohidratos de acción rápida 824, compensador de comidas 840 y lógica de implementación basal de bucle abierto 850. Procesar datos del sensor 806 contiene la estrategia para determinar un valor de glucosa a partir de valores de glucosa medidos disponibles. El punto fijo de insulina 804 es la tasa de infusión de insulina usada para mantener la glucosa basal objetivo. La predicción de glucosa 838 predice el valor de glucosa para los ciclos de control desde los últimos valores de mediciones de glucosa conocidos. El módulo de recomendación de insulina 846 computa la dosis de insulina para mantener la glucosa basal. El compensador de ejercicio 822 gestiona un nivel de actividad física incrementado. La ingestión de carbohidratos de acción rápida 824 gestiona la ingestión de carbohidratos de acción rápida para compensar una caída de glucosa esperada. El compensador de comidas 840 computa la distribución de las inyecciones intravenosas rápidas de insulina para un acontecimiento de comida. La implementación basal de bucle abierto 850 implementa la insulina basal durante la observación controlada 700 por el controlador de bucle abierto (FIG. 7).

Control y mantenimiento (nivel superior)

En el nivel superior de las operaciones de ALGO 510 están los problemas relacionados con el control y mantenimiento. Los módulos de control y mantenimiento son: inicialización/preparación 800, gestión de ciclos perdidos 801, mapeo de acontecimientos 802, depósitos de insulina 848 y anulación de la insulina 836. El módulo de inicialización/preparación 800 es el vector de estado de ALGO que controla la información anterior, actual y futura (memoria de ALGO). El módulo de gestión de ciclos perdidos 801 que se ha analizado anteriormente en una sección previa gestiona el reinicio de las llamadas de APTS o ALGO que se omitieron por cualquier motivo. El mapeo de acontecimientos 802 mapea el conjunto de acontecimientos externos con respecto al conjunto de acontecimientos internos. Los depósitos de insulina 848 controlan la recomendación de insulina de diversos módulos como componentes para llenar y vaciar los depósitos. La anulación de la insulina 836 anula cualquier componente de la insulina que proceda de los términos de prealimentación de la acción de control de la administración de insulina final. El control interno de inyecciones intravenosas rápidas 844 proporciona las inyecciones intravenosas rápidas de prealimentación que resultan de un acontecimiento de comida.

Monitorización e información sobre el estado

Los módulos para monitorizar e informar sobre el estado son: Actualización de glucosa 808 que verifica la disponibilidad de nuevos valores de medición de glucosa. La glucosa desactualizada 814 informa al usuario de si existe una necesidad de obtener un valor de glucosa reciente. La inyección intravenosa rápida automática 810 tiene en cuenta cualquier discrepancia en la insulina por medio de solicitudes de inyección intravenosa rápida automática. La advertencia no hay glucosa es una protección en caso de fallo que avisa al sistema de que la PU 502 (FIG. 5) no responde y de que un bucle de vigilancia debe comenzar la cuenta atrás del temporizador, tal como se describe anteriormente en una sección previa. El aviso de comidas 842 informa al usuario para que comience a comer.

Acciones correctivas

Los módulos para las acciones correctivas son: rectificación de carbohidratos 834, intervención de alto contenido de glucosa 832, intervención de bajo contenido de glucosa 826, zona de glucosa de la comida 820 y gestión de discrepancias 818. La rectificación de carbohidratos 834 revisa el acontecimiento de comida introducido previamente (valor de carbohidratos) y la administración de insulina se corrige en consecuencia. La intervención de alto contenido de glucosa 832 corrige el alto nivel de glucosa por medio de la administración de insulina. La intervención de bajo contenido de glucosa 826 corrige el nivel de bajo contenido de glucosa por medio de la ingestión de carbohidratos de acción rápida. La zona de glucosa de la comida 820 define el objetivo de glucosa como una banda, en lugar de una línea. La gestión de discrepancias 818 gestiona los depósitos de insulina cuando se identifica la discrepancia entre la insulina solicitada frente a la insulina administrada.

Gestores de acontecimientos importantes

Los módulos para gestionar los acontecimientos importantes son: Ejercicio preparatorio 828 e inyección intravenosa rápida solicitada 830. El ejercicio preparatorio 828 revisa el requerimiento basal con anticipación al controlador de ejercicio e informa al controlador al comienzo del ejercicio específico. La petición de inyección intravenosa rápida solicitada 830 para inyección intravenosa rápida de insulina adicional. Aunque las descripciones de los módulos anteriores del EA 518 eran de carácter general para determinados módulos, en lo sucesivo se proporciona un análisis más detallado sobre dichos módulos.

Mapeo de acontecimientos

Después de ejecutar los módulos de inicialización y preparación y gestión de ciclos perdidos 800 y 801, entonces, el ALGO 510 ejecuta el módulo de mapeo de acontecimientos 802 para adquirir información sobre perturbaciones externas a través de los acontecimientos recibidos por APS 502. Por ejemplo, en un modo de realización, los acontecimientos externos se presentan en una lista desplegable en la interfaz de usuario 512 del APTS 500 para la selección del usuario. El ALGO 510 opera sobre acontecimientos que son específicos para el propio ALGO. Estos se llaman acontecimientos internos. Cada acontecimiento externo seleccionado por el usuario se mapea con respecto a como máximo un acontecimiento interno. Se proporcionan a los acontecimientos externos descriptores para que el usuario final se relacione con ellos, y/o activen una acción de ALGO cuando se seleccionan. Estos descriptores pueden ser específicos del usuario y pueden admitir múltiples idiomas.

En un modo de realización, podría haber múltiples descriptores de acontecimientos externos en relación con el mismo acontecimiento interno. Por ejemplo, "inyección intravenosa rápida automática" e "inyección intravenosa rápida de cebado" son descriptores de acontecimientos externos separados, pero internamente ambos de estos acontecimientos apuntan al mismo tipo de acontecimiento interno (llamado inyección intravenosa rápida automática). Por tanto, es posible tener múltiples acontecimientos externos que apuntan al mismo acontecimiento interno (muchos con respecto a uno). La tabla 3 enumera los acontecimientos internos fundamentales a partir de los que funciona el ALGO 510.

Tabla 3: Lista de acontecimientos internos fundamentales para EA

Punto fijo de insulina

Luego, el EA 518 ejecuta el módulo de punto fijo de insulina 804. Para este módulo 804, la tasa de insulina basal (es decir, la tasa de infusión de insulina usada para mantener un valor de glucosa) es el perfil basal que normalmente se define para un día típico. Sin embargo, un día típico como se ve mediante el estilo de vida del sujeto y que se usa para dirigir el ALGO 510 es bastante diferente. Por ejemplo, y como se usa en el presente documento, existen dos clases de perfiles de insulina basal: (a) perfil de bomba y (b) perfil definido de ALGO. Para el perfil de bomba, la tasa basal varía a lo largo del día. Las tasas programadas previamente pueden incluir insulina para cubrir partes de la comida y otros acontecimientos típicos. El perfil definido es específico del usuario y se adapta a la programación y al estilo de vida diarios del sujeto. Para el perfil definido de ALGO, el perfil se determina después de analizar y eliminar las inyecciones intravenosas rápidas necesarios para gestionar acontecimientos como las comidas y el ejercicio. Para determinar el perfil definido de ALGO, el EA 518 usa monitorización de datos intensiva para un nuevo sujeto. Para los sujetos que se han sometido a un experimento, estos datos clínicos se usan para determinar el perfil definido de ALGO. Estos se determinan a través de protocolos experimentales y herramientas de soporte, tales como herramientas de transformación o inversión. La tasa basal extraída así determinada es independiente de los acontecimientos relacionados con las dosis de insulina. Este perfil definido de ALGO se guarda como el conjunto basal.

El conjunto basal se muestra como una matriz de tres columnas, que se define por un archivo de inicialización del sujeto (es decir, el archivo ini del sujeto). Contiene el tiempo, la tasa basal y la glucosa basal. La tabla 4 es un ejemplo de un conjunto basal en el archivo de inicialización del sujeto.

Tabla 4: Ejemplo de conjunto basal

La tasa basal es una función tanto del valor de glucosa objetivo como de la hora del día. El perfil de tasa basal diaria se define como un caudal fijado de insulina en U/h durante un tiempo ta. El tiempo ta se define en minutos desde la medianoche, y el perfil de insulina se dispone en orden ascendente de acuerdo con el tiempo. Se implementa un caudal fijado hasta que se alcanza el próximo conjunto de caudales de insulina. El perfil de tasa basal se repite por sí mismo durante cada periodo de tiempo de 24 horas. La tasa de insulina basal es integral para el mantenimiento de la glucosa objetivo. La tasa de insulina administrada y el valor de glucosa correspondiente determinan la tasa de insulina necesaria para mantener un valor de glucosa objetivo dado. Se supone que la tasa de insulina es una función lineal de la glucosa objetivo y viene dada de acuerdo con la ecuación (5):

donde GB es un valor de glucosa objetivo, lB es una tasa de insulina para mantener un valor de glucosa de GB, es

un valor de glucosa definido en el conjunto basal para una hora determinada del día, 1 es una tasa de insulina A i

r B „

necesaria para mantener un valor de glucosa de ^ , y A (i es una tasa de insulina por cambio de glucosa.

Por ejemplo, la FIG. 10 muestra gráficamente la relación de puntos fijos anterior. En particular, la línea X en la FIG.

A l 0,1 u / h

10 muestra la tasa de insulina basal al mediodía en función del punto fijo de glucosa cuando ■ = se define AG 10 m g / d l como una constante. La línea Y similar muestra lo mismo para la tasa de insulina basal a medianoche, pero a un punto fijo más bajo (0,8 frente a 1,3). Por favor, obsérvese que, sin embargo, que la pendiente se exagera para mostrar esta relación insulina-glucosa y es solo un ejemplo ilustrativo.

Procesar datos del sensor

Después de ejecutar el módulo de punto fijo de insulina 804, el EA 518 ahora procede a llamar al módulo de procesar datos del sensor 806. Los datos se obtienen de un sensor, tal como, por ejemplo, un sensor de glucosa 604 (FIG. 7) por el módulo de procesar datos 806 y se clasifican como datos sin procesar. Junto con el estado del sensor, los datos sin procesar se procesan y analizan para determinar el valor de glucosa y el tiempo de medición. Por ejemplo, los procedimientos deben eliminar los valores extremos de los conjuntos de datos actuales y anteriores, y otra información, tal como el estado del sensor y los sensores secundarios para determinar el valor de glucosa más confiable y exacto. Una de dos funciones de procesamiento es el uso, dependiendo del tipo de sensor que haya proporcionado los datos sin procesar.

La primera función de procesamiento encuentra y usa el punto de datos sobre glucosa introducidos más recientes. La función busca cualquier dato sobre glucosa disponible para un ciclo de control yendo hacia atrás a través de cada ciclo de control hasta que localiza con éxito el conjunto de valor(es) de glucosa o se queda sin datos sobre glucosa. Si el conjunto de datos sobre glucosa está vacío, entonces, se devuelve un vector de glucosa vacío. Tras determinar un conjunto de glucosa no vacío, se define una ventana de tiempo de duración Te como (tG-Tc,tG). Se informa de la

!■

G [ K ] = ^ —

media del/de los valor(es) de glucosa, " . Valor de glucosa en el índice Kesim° para el ciclo kesim°. El registro del tiempo para glucosa tG [K] asignado es tiempo de finalización para el ciclo de control seleccionado. La FIG. 11 muestra gráficamente la selección del intervalo de tiempo para la primera función de procesamiento usando las variables anteriores.

La segunda función de procesamiento se usa cuando las características de funcionamiento del sensor de glucosa actual proporcionan un intervalo de datos tal como, por ejemplo, un monitor continuo de glucosa subcutáneo. En este ejemplo, el intervalo de datos tiene un límite inferior de 20 mg/dl y un límite superior de 450 mg/dl. En este ejemplo, no se especifican otros posibles límites de tasa de glucosa. En un modo de realización, el sensor registra datos sobre glucosa no válidos fuera del intervalo asignando a los datos un valor de cero. Como tales, estos valores de glucosa no válidos =0) se retiran, entonces, de los datos sin procesar mediante el módulo de procesar datos del sensor 806 y no se incluirán en ningún análisis cuantitativo. En un modo de realización, se presenta un mensaje emergente para advertir al usuario de los límites superior e inferior.

Cuando se computa un valor de glucosa para el EA, solo se consideran los datos del sensor primario. Se selecciona(n) el/los valor(es) de glucosa más reciente(s) disponible(s). Una ventana de tiempo de duración Te se define como: (t1-Tc,ti). Se eligen los valores de glucosa disponibles en la ventana seleccionada y se selecciona la mediana: G[K] = mediana(S<> " - 'S i -¿'i ) . Valor de glucosa en el índice Kés¡m° para el ciclo kés¡m°. La mediana del tiempo se computa y devuelve como íg[K] = mediana( ^t o ^{k t k t k t} ' ^k ). Obsérvese que el tiempo medio íg[K] se redondeará al límite del ciclo de control más cercano por el EA 518 si fuera necesario. La FIG. 12 muestra la selección del intervalo de tiempo para la segunda función de procesamiento.

Actualización de glucosa

Después de obtener y procesar los datos sin procesar, el EA 518, entonces, procede a llamar al módulo de actualización de glucosa 808. La actualización de glucosa explica un aspecto de la disponibilidad de glucosa y su implicación en el funcionamiento interno del ALGO 510. No es directamente pertinente para usuarios finales fuera del ALGO 510. Obtener el valor de glucosa más reciente es crucial para mantener el control glucémico. Debido al retardo del sensor y/o fallo del sensor, se necesita un predictor de glucosa para obtener una estimación de la glucosa actual. Cuando el sensor proporciona nuevos valores de glucosa, el módulo de recomendación de insulina 846 revisa la predicción de glucosa usando la glucosa medida más reciente. Sin embargo, en ausencia de nueva información sobre la glucosa, en su lugar, la glucosa predicha determinada durante el ciclo de control se usa para predecir la glucosa para el ciclo actual. En este caso, la información sobre el estado se usa eficazmente para proseguir desde el último ciclo de control al nuevo ciclo actual para predecir la glucosa. Por tanto, el módulo de actualización de glucosa 808 identifica si está disponible o no un nuevo conjunto de mediciones de glucosa y si se ha de usar la última glucosa predicha y continuar.

Inyección intravenosa rápida automática

Entonces, el EA 518 llama al módulo de inyección intravenosa rápida automática 810 para tener en cuenta cualquier discrepancia en la insulina accediendo a la información de la bomba en relación con las solicitudes de inyección intravenosa rápida automática. Existen varios motivos por los que se necesita acceso físico a la bomba de insulina, tales como, por ejemplo, cambio de batería, cambios en el tubo de insulina o el usuario desea solicitar manualmente una inyección intravenosa rápida. Un aspecto de esto es que se ve cualquier inyección intravenosa rápida solicitada manualmente al inicio de cada ciclo de control en el término de insulina neta distribuida. Puesto que el ALGO 510 no recomendó la inyección intravenosa rápida solicitada manualmente, el EA 518 considerará esta inyección intravenosa rápida como un excedente de dosis. Entonces, el excedente de insulina determinado se tiene en cuenta y ajusta por retroalimentación durante las futuras acciones de control. Para gestionar sistemáticamente este caso, se debe activar un acontecimiento de inyección intravenosa rápida automática antes de la acción de la inyección intravenosa rápida manual. Entonces, el ALGO 510 espera una cantidad de excedente igual a la cantidad de inyección intravenosa rápida automática introducida. El uso de este acontecimiento también garantiza que todas las inyecciones intravenosas rápidas manuales se tengan en cuenta apropiadamente. La inyección intravenosa rápida solicitada no resuelta es el resto de la inyección intravenosa rápida solicitada. La inyección intravenosa rápida no resuelta tiene una ventana de tiempo finita en la que se debe resolver la cantidad de inyección intravenosa rápida automática. La cantidad se resuelve con un excedente de dosis; de otro modo, la inyección intravenosa rápida no resuelta (es decir, el equilibrio de la cantidad de inyección intravenosa rápida automática) se fija en cero. Otro motivo para limitar el acontecimiento a una duración finita es borrar la memoria como una precaución de seguridad en caso de que el usuario le informe al banco de pruebas del excedente, pero no solicite una inyección intravenosa rápida desde la bomba. Un mensaje de advertencia no hay glucosa se presenta por un módulo de aviso de que no hay glucosa 812 al usuario antes de fijar la cantidad de inyección intravenosa rápida automática no resuelta en cero.

Medición de glucosa desactualizada

Después de obtener y procesar los datos sin procesar y enviar una advertencia, si procede, el EA 518, entonces, procede a llamar al módulo de glucosa desactualizada 814. La exactitud y fiabilidad de un predictor de glucosa se deteriora a medida que se incrementa la duración de la predicción. Si el último valor de glucosa recibido es más antiguo que una determinada ventana de tiempo especificado, el ALGO 510 aplica el modo de observación controlada 700 de bucle abierto (FIG. 7) como precaución de seguridad e implementa un control basal programado previamente. Al funcionar en el modo de observación controlada 700, el tratamiento está limitado al programado en el perfil basal de la bomba de insulina y, si fuera necesario, se aumentará mediante un subconjunto de funcionalidades expuestas. La tarea del módulo de glucosa desactualizada 814 es proporcionar información en relación con el estado de glucosa desactualizada pendiente por medio de mensajes emergentes. Cuando se alcanza un estado de glucosa desactualizada, el módulo de glucosa desactualizada 814 cambia las marcas apropiadas para aplicar el modo de observación controlada 700. Proporcionar una nueva medición de glucosa primaria rectificará la situación. En consecuencia, la glucosa desactualizada indica que la predicción de glucosa ya no es válida, y fuerza al controlador en un modo de observación controlada 700.

Las siguientes advertencias se proporcionan por el módulo de glucosa desactualizada 814: advertencia previa al operador, advertencia al operador y medición de glucosa desactualizada. Para la advertencia previa al operador, se advierte previamente al usuario del vencimiento pendiente por medio de la ventana de registro. En los ciclos de advertencia de cuenta atrás antes del vencimiento, se informa al usuario de manera iterativa de que quedan n número de minutos antes de un periodo de vencimiento. Además, aparece el siguiente mensaje: “ADVERTENCIA: La glucosa pronto estará desactualizada. Por favor, introducir la glucosa actual”. Para advertir al operador, se fuerza un mensaje emergente en el último ciclo del periodo de vencimiento y en cada ciclo después de esto hasta que se reciba una nueva medición de glucosa. Este mensaje aparece: “ADVERTENCIA: La glucosa estará desactualizada en el próximo ciclo. Por favor, introducir la glucosa actual”. Para una medición de glucosa desactualizada, durante una condición de glucosa desactualizada, el ALGO 510 se forzará a sí mismo en el modo de observación controlada 700 de bucle abierto si el ALGO 510 está en el modo de control puro 600 de bucle cerrado, e implementa el perfil de insulina basal del usuario. Además, este mensaje aparece: “ADVERTENCIA: Glucosa desactualizada. ¡Ejecutar la observación controlada! Por favor, introducir la glucosa actual”. Luego, el EA 518 comprueba para ver si existen suficientes mediciones de bG en los datos obtenidos y procesados para continuar en el punto de flujo del procedimiento 816. Si no es así, el EA procede al punto de flujo del procedimiento 850 que se analiza en una sección posterior. Si es así, entonces, el EA 518 continúa con el módulo de gestión de discrepancias 818.

Gestionar la discrepancia entre los resultados esperados y los resultados reales

El módulo de gestión de discrepancias 818 comprueba para ver si la insulina solicitada determinada por EA 518 es diferente de la insulina distribuida desde la bomba. Si es así, entonces, el EA 518 marca esto como una discrepancia en la insulina solicitada y presenta una notificación al usuario en la interfaz de usuario 512 (FIG. 5). Entonces, se necesita resolver la discrepancia entre la insulina solicitada y administrada por el usuario y/o profesional sanitario, ya que la causa de la discrepancia es probablemente independiente del APTS 500 (por ejemplo, bomba de insulina defectuosa).

Zona de glucosa de la comida

Entonces, el EA 518 procede al módulo de la zona de glucosa de la comida 820. En este punto, el módulo de la zona de glucosa de la comida 820 simplemente fija el objetivo de glucosa como una banda, en lugar de una línea. Esta banda se usa por ALGO 510 en el modo de control puro 600 de bucle cerrado como el objetivo 601, que también proporciona un punto fijo 603 que se usa por el controlador basal 628 (FIG. 6). Se ha de apreciar que el predictor de glucosa 626 usado por el controlador basal 628 como introducción de datos de acción no tiene en cuenta los cambios de glucosa debidos a una comida. En cambio, una comida está cubierta por una distribución de la dosis de insulina predeterminada. Esta distribución de la dosis de insulina se determina para minimizar de la mejor manera el aumento de glucosa y para llevar la glucosa al nivel de glucosa objetivo lo más rápido posible con mínimo subimpulso. El aumento de glucosa con respecto a la ingesta de comidas no se puede eliminar completamente. Esto se espera, puesto que existe un retardo de aproximadamente 30-60 minutos en la acción de la insulina máxima. La dosificación de insulina obtenida se optimiza para minimizar el aumento de glucosa debido a la comida. La banda de la zona de glucosa objetivo relacionada con la comida se define, por tanto, alrededor del acontecimiento de comida como una región limitada por los límites de glucosa objetivo superior e inferior. Con respecto a la zona objetivo definida, la FIG.

13 muestra cuatro situaciones diferentes: (a) en la zona de glucosa; (b) por encima de la zona de glucosa; (c) por debajo de la zona de glucosa; y (d) ningún nuevo valor de glucosa.

(a) En la zona de glucosa

Si el valor de glucosa predicha se encuentra en los límites de la zona de glucosa, entonces, la glucosa del sujeto se considera en límites aceptables. El controlador basal 628 en este caso solo necesita la insulina basal para mantener el control glucémico.

(b) Por encima de la zona de glucosa

Si la glucosa predicha se encuentra por encima del límite de glucosa superior, entonces, el sujeto se considera como que tiene poca administración de insulina. El controlador basal 628 computa la desviación de la glucosa con respecto al límite de glucosa superior. La acción del controlador basal 628 tiene en cuenta esta desviación y frenará este aumento no tenido en cuenta.

(c) Por debajo de la zona de glucosa

Si la glucosa predicha se encuentra por debajo del límite de glucosa inferior, entonces, se considera que al sujeto se le ha administrado insulina en exceso. El controlador basal 628 computa la desviación de la glucosa con respecto al límite de glucosa inferior. La acción del controlador basal 628 tiene en cuenta esta desviación y frenará esta caída no tenida en cuenta.

(d) Sin actualización sobre la glucosa

La zona objetivo cubre el aumento y caída de una respuesta relacionada con la comida anticipada. Un caso especial surge cuando la glucosa no se actualiza. Sin ninguna actualización sobre la medición de glucosa, la glucosa predicha para el ciclo de control actual Tc es un valor de glucosa sin tener en cuenta el aumento o caída relacionado con la comida de la glucosa. Sin embargo, los límites de la zona objetivo son una función del tiempo. En general, esto significa que la glucosa predicha es más baja cuando la comida empieza a tener efecto y más alta cuando la comida se está agotando. Este efecto se acentúa con los límites de las zonas de comida ascendentes y descendentes. El EA 518 gestiona este caso manteniendo los límites limítrofes usados por última vez con la última medición de glucosa recibida. Estos valores objetivo superior e inferior se mantienen fijados para todos los futuros ciclos de control, hasta que aparezca una nueva medición. Esto alivia el problema hasta cierto punto.

Ejercicio preparatorio y ejercicio

Luego, el EA 518 evalúa si el paciente está implicado en el ejercicio por medio del módulo de ejercicio 822. Con un nivel incrementado de actividad física, el requerimiento de mantener la energía también se incrementa. La glucosa, que es la fuente de energía, se usa a una tasa más alta para respaldar la actividad incrementada. Como tales, los tres supuestos de comportamiento fisiológico se realizan como sigue. El primer supuesto es que al comienzo del ejercicio, existe una caída en los niveles de glucosa. El segundo supuesto es que la caída de glucosa es rápida, comenzando y finalizando aproximadamente 10 minutos después del inicio y final del ejercicio físico. El supuesto final es que una vez que el nivel de actividad física vuelve a la normalidad, existe una fase de recuperación, ya que la glucosa se almacena como glucógeno en los músculos e hígado. En consecuencia, el ejercicio se gestiona en fases mediante los módulos de ejercicio y ejercicio previo 822 y 828, de manera receptiva.

El módulo de ejercicio preparatorio 828, que el EA 518 llama posteriormente en el flujo del procedimiento, eleva la glucosa con anticipación al ejercicio incrementando el punto fijo de glucosa de modo que el nivel de glucosa pueda caer de forma segura durante el ejercicio. Como tal, un tratamiento predeterminado normal para gestionar el ejercicio es reducir la insulina basal con anticipación al ejercicio. El efecto de reducir la insulina sobre la glucosa depende de la farmacodinámica de la insulina. Entonces, el nivel de insulina basal más bajo se mantiene durante la duración del ejercicio. Además, si los niveles de glucosa no se elevan lo suficiente al inicio del ejercicio, el sujeto podría controlar su nivel de glucosa consumiendo carbohidratos de acción rápida. Esto provoca que el nivel de glucosa aumente rápidamente.

El sujeto se prepara para el ejercicio desencadenando un acontecimiento de ejercicio preparatorio seleccionando una actividad y/o nivel de actividad de una lista proporcionada en la interfaz de usuario 512 (FIG. 5). La actividad y/o el nivel de actividad seleccionados tienen una caída de glucosa anticipada correspondiente. Hasta que se desencadene el acontecimiento de ejercicio, el cambio de la glucosa objetivo viene dado por la ecuación (6):

ACj. - A r f . i» .

donde ^{A G t} es el cambio del valor de glucosa objetivo, y p es la subida anticipada (aumento) de la concentración de glucosa, que, para el ejercicio, el valor es negativo, puesto que el ejercicio provoca una caída de la glucosa. Así, la glucosa objetivo (es decir, el objetivo 601) viene dada por la ecuación (7):

ÚT = G., + AGj. (7).

De nuevo, una vez que comienza la actividad de ejercicio, el cuerpo puede necesitar menos insulina y puede mantener un requerimiento de insulina basal más baja durante la duración del ejercicio. Tras finalizar el ejercicio, el nivel basal reducido vuelve a la configuración basal normal de cierta manera gradual predefinida.

Después de que haya comenzado el ejercicio, el módulo de periodo de ejercicio 822 proyecta una caída de glucosa durante la duración del ejercicio. Cuando se desencadena el acontecimiento de ejercicio, se desactiva el ejercicio preparatorio. El estado basal se evalúa de nuevo al comienzo del acontecimiento de ejercicio. Si el ejercicio preparatorio no elevó el nivel de glucosa a la cantidad deseada, entonces, se solicita al usuario por el ALGO 510 en la interfaz de usuario 512 (FIG. 5) que consuma carbohidratos de acción rápida para complementar el aumento. El vector de subida de glucosa gana un componente debido al consumo de carbohidratos de acción rápida (como se explica en lo sucesivo en la sección titulada “carbohidrato de acción rápida”). La caída de glucosa esperada provocada por la actividad física se expresa de acuerdo con la ecuación (8) como:

J^!

donde se usa, entonces, para computarla insulina basal necesaria (es decir, la subida de glucosa). Obsérvese que p es un valor negativo para el ejercicio. Los efectos del ejercicio y los carbohidratos de acción rápida se modelan como vectores de subida de glucosa que se mueven en sentidos opuestos en una curva de respuesta al aumento de glucosa normalizada.

Después del ejercicio, el módulo de ejercicio 822 proporciona un periodo de recuperación del ejercicio que normaliza gradualmente la tasa basal según el requerimiento del conjunto basal. En esta implementación, la duración del

ejercicio está definida previamente en el vector:Jt-7 . Una vez que el ejercicio se haya acabado, la subida de glucosa I -i' j t

_{debida al ejercicio} AG es 0. La discontinuidad se atenúa usando ■’ factor de recuperación, y = duración de

la recuperación en minutos. Si la tasa basal de insulina del conjunto basal viene dada por ' 1 entonces, se puede determinar usando la ecuación (9):

donde ■' es la hora a la que se completó el ejercicio, y t es la hora actual.

Carbohidrato de acción rápida

Después de terminar con el módulo de ejercicio 822, entonces, el EA 815 llama al módulo de carbohidratos de acción rápida 824 para proporcionar una actualización de un vector de subida de glucosa debido a una ingestión de carbohidratos de acción rápida si así se indica por el paciente en la interfaz de usuario 512 (FIG. 5). El vector de

subida de glucosa ^{A¿',' í} se analiza usando un perfil de subida de glucosa esperado y un perfil de subida de glucosa relativo. El perfil de subida de glucosa esperado es un vector de subida de glucosa predefinido, y se normaliza por gramo de ingesta de carbohidratos y por aumento en mg/dl. El vector de subida de glucosa relativo es el producto del

vector de subida normalizado ' Jf‘ , la cantidad de carbohidratos de acción rápida consumidos en AFC [g], y el

aumento de glucosa esperado por gramo de carbohidrato ^{K í} [mg/dl/gj. Por tanto, el vector de subida de glucosa se puede describir y determinar por la ecuación (10):

Intervención de bajo contenido de glucosa

Luego, el EA 518 llama al módulo de intervención de bajo contenido de glucosa 826 que mantiene la seguridad del usuario definiendo las condiciones que aseguran el aumento del valor de glucosa. En una situación de bajo contenido de glucosa, tal como cuando ALGO 510 no ha logrado mantener el nivel de glucosa por encima de un límite glucémico aceptable de manera oportuna, el EA 518 intervendrá en base a la información proporcionada a partir de este módulo. El propósito de esta intervención es devolver al sujeto a un intervalo glucémico normal mediante la ingestión de carbohidratos de acción rápida. Con el EA todavía activo, el ALGO 510 verá el incremento de la glucosa medida y potencialmente contrarrestará esta subida de glucosa recomendando insulina adicional. Sin embargo, el módulo de intervención de bajo contenido de glucosa 826 permite que la glucosa aumente con una recomendación de insulina más conservadora.

En un modo de realización, ALG se define como la cantidad de carbohidratos de acción rápida necesaria para reducir el nivel de glucosa. Entonces, la subida de glucosa esperada viene dada por la ecuación (11):

AC;/' - AG'.’j A,,lK?

A r'- Ír

donde ' es la subida de glucosa debida a la ingesta de carbohidratos de acción rápida, ALG es la cantidad de

carbohidratos de acción rápida para la intervención de bajo contenido de glucosa, ^{K 1'"} es el aumento de glucosa por gramo de carbohidratos. La FIG. 14 muestra gráficamente la subida de glucosa para la ingesta de carbohidratos de

acción rápida. Modificando el punto fijo de glucosa Gsp en una cantidad igual al aumento esperado de 1 ’ '■ , el ALGO 510 no contrarrestará el aumento atribuido a la ingesta de carbohidratos de acción rápida. Además, con el tiempo, se debe reestablecer Gsp con respecto al punto fijo original. El vector de subida para el punto fijo se define

como un producto de

y el término de ganancia linealmente descendente

y viene dado por la ecuación (12):

Por tanto, el punto fijo viene dado de acuerdo con la ecuación (13):

La FIG. 15 muestra gráficamente el cambio del punto fijo relativo a lo largo del tiempo. Es posible que se produzcan múltiples intervenciones de bajo contenido de glucosa cuando la glucosa no aumenta lo suficientemente rápido. Esto también da lugar a una acumulación de Gsp debido a los múltiples acontecimientos de intervención de bajo contenido de glucosa. La intervención de bajo contenido de glucosa, en lugar de añadir los efectos, elimina la parte pendiente

restante de la última intervención de bajo contenido de glucosa antes de añadir ■“ para el acontecimiento de intervención de bajo contenido de glucosa actual. Después de dicha intervención, el eA 518 llama al módulo de ejercicio preparatorio 828, que, desde que se analiza anteriormente en la sección previa titulada "ejercicio preparatorio y ejercicio", no se proporciona ningún otro análisis.

Inyección intravenosa rápida solicitada

El EA 518 usa el módulo de inyección intravenosa rápida solicitada 830 cuando el usuario solicita a la bomba que administre una inyección intravenosa rápida adicional de insulina ACB, a través del APS 500. Sin embargo, el EA 518 reconoce e implementa el acontecimiento de inyección intravenosa rápida solicitada por medio del ALGO 510 de forma diferente para cada uno de los modos de control. Para el modo de control puro 600 de bucle cerrado (FIG. 6), el acontecimiento de inyección intravenosa rápida solicitada puede forzar una administración temprana de insulina y, por tanto, puede modificar la futura distribución de las recomendaciones de insulina. Además, cuando esté en el modo de control puro 600, la inyección intravenosa rápida solicitada ACB estará por encima de la cantidad de insulina requerida para lograr la glucosa objetivo. En consecuencia, en futuros ciclos de control, el EA 518 tiene en consideración ACB, y ajusta la recomendación en consecuencia. Para el modo de observación controlada 700 de bucle abierto (FIG. 7), el módulo de inyección intravenosa rápida solicitada 830 posibilita que el sujeto controle su tratamiento individual durante el modo de observación controlada 700 introduciendo, por medio de la interfaz de usuario 512 (FIG. 5), la inyección intravenosa rápida para cubrir acontecimientos tales como, por ejemplo, la ingesta de comidas y el nivel de glucosa elevado.

Intervención de alto contenido de glucosa

El módulo de intervención de alto contenido de glucosa 832 posibilita que EA 518 corrija un estado de hiperglucemia. El usuario introduce, por medio de la interfaz de usuario 512 (FIG. 5), la cantidad de corrección AhG como un acontecimiento de intervención de alto contenido de glucosa. Los dos modos de control 600 y 700 administran la cantidad de intervención junto con una recomendación, que se genera por el modo respectivo. La inyección intravenosa rápida solicitada es insulina "vista por ALGO", mientras que la insulina administrada para cubrir un acontecimiento de intervención de alto contenido de glucosa "no es vista por ALGO". En el modo de control puro 600 de bucle cerrado, la parte de retroalimentación del ALGO 510 está oculta para la cantidad de intervención con respecto a la insulina. El módulo de anulación de la insulina 836 (analizado en lo sucesivo en una sección posterior) elimina la cantidad de insulina relacionada con una intervención de alto contenido de glucosa. Esto significa que la retroalimentación no reduce la cantidad de insulina de futuras acciones de control. En el modo de observación controlada 700 de bucle abierto, la cantidad de intervención para altos niveles de glucosa se suma con una recomendación de bucle abierto para proporcionar la recomendación de insulina neta.

Rectificación de carbohidratos: Revisar la última ingesta de comidas

Después de que el sujeto haya indicado el consumo de una comida de AM gramos de carbohidratos al ALGO 510, existe la posibilidad de que la cantidad introducida se pueda tener que revisar debido a uno de varios motivos potenciales. Estos motivos incluyen: cálculo erróneo/entrada anterior incorrecta; el sujeto no podía consumir tanto como se anticipó anteriormente (o consumió más de lo que se anticipó); el consumo de alimentos se extendió durante un periodo de tiempo más largo y de ahí que se necesite distribuir de nuevo el tratamiento; y en un caso extremo, la cancelación de la comida. Con los motivos anteriores en mente, el EA 518 llama al módulo de rectificación de carbohidratos 834, que se ejecuta en las siguientes condiciones. En primer lugar, debe existir un acontecimiento de comida en el tiempo fiw y de la cantidad AM. En segundo lugar, un acontecimiento de corrección en la comida en el tiempo ímc y cantidad ^A ' ; ^u se ha introducido por el usuario. En un modo de realización alternativo, el acontecimiento

de comida se define como la comida restante J ■ .S i se cumplen ambas condiciones, entonces, se realiza la corrección con respecto a la cantidad de insulina y la distribución, siempre que se cumpla la siguiente condición adicional de la ecuación (14):

O 4)'

donde ^r c ^1' es el tiempo en minutos y es la ventana de tiempo permitida para corregir la entrada de la última comida, y 0 < "■ <AM (solo para el caso de comida restante). Si se cumple la última condición anterior, entonces el módulo de rectificación de carbohidratos 834 se ejecuta adicionalmente, de lo contrario, el módulo regresa al EA 518 sin realizar ninguna acción.

En otro procesamiento, el módulo 834 reemplaza la distribución de insulina obtenida para AM en el tiempo fw por la

_{nueva distribución de insulina computada para la nueva cantidad de comida} A _{' r . La distribución se implementa con} J1"

respecto al tiempo ím y no con respecto a tuc. Para el caso de comida restante, ' - , viene dada por la ecuación (15):

El módulo 834 identifica el último acontecimiento de comida que se produce en el (a) momento en el que se produjo

y (b) la cantidad. Si se satisfacen los supuestos 1 y 2, los cálculos del módulo: Para ' ⁴ < ^U ’ encontrar la distribución de insulina. Cambiar el tiempo de la distribución en el momento en el que se produjo la última comida. Para AM encontrar la distribución de insulina. Cambiar el tiempo de la distribución en el momento en el que se produjo la última comida. Desde los lapsos de tiempo correspondientes realizar: Desde el vector de INYECCIÓN INTRAVENOSA RÁPIDA

RELACIONADA CON LA COMIDA, restar c la distribución de insulina relacionada y añadir una distribución AM.

. . am

Desde el vector de ACONTECIMIENTO INTERNO DE INYECCION INTRAVENOSA RAPIDA, restar ' la distribución de insulina relacionada y añadir una distribución AM. Este procesamiento adicional del módulo de rectificación de carbohidratos 834 se aclara además mediante un ejemplo mostrado en la FIG. 16 y analizado en lo sucesivo.

La comida es un acontecimiento de comida y la corrección en la comida es un acontecimiento realizado por el módulo de rectificación de carbohidratos 834. En el ejemplo proporcionado, en el tiempo ím = 495 se introduce un acontecimiento de comida de 100 g que necesita [2 0 5 0 0 3 0 0 2] como distribución de insulina. INYECCIÓN INTRAVENOSA RÁPIDA RELACIONADA CON LA COMIDA hasta que t=525 sea [3 15] y el ACONTECIMIENTO INTERNO DE INYECCIÓN INTRAVENOSA RÁPIDA sea [0 0 3 0 0 2]. La INYECCIÓN INTRAVENOSA RÁPIDA RELACIONADA CON LA COMIDA muestra que existen contribuciones de a la insulina adicionales que proceden, por ejemplo, de una comida previa. Su existencia es importante y no de dónde procede la contribución para el problema actual. En í^mc=525 se introduce la corrección con respecto a la comida. La información ahora es que para la entrada de comida de 100 g en ím =495, solo se consumieron, en realidad, 60 g, lo que completa las etapas 1 y 2. Así que en la etapa 3, el módulo 834 determina en primer lugar la insulina para 60 g, que es [1.5030020001.5] en la etapa 4. Debido a que ALGO 510 no recuerda qué distribución para 100 g había en la etapa 5, se computó de nuevo para 100 g como [2 0 50 0 30 02] en la etapa 6. Ambos vectores (60 g y 100 g) se desplazan a t=500 en la etapa 7 (mostrado mediante flechas) y tanto la INYECCIÓN INTRAVENOSA RÁPIDA RELACIONADA CON LA COMIDA como el ACONTECIMIENTO INTERNO DE INYECCIÓN INTRAVENOSA RÁPIDA se computan de nuevo en las etapas 8 y 9.

Si la rectificación de carbohidratos no es aplicable, se presenta el siguiente mensaje emergente en la interfaz de usuario 512 (FIG. 5): “ADVERTENCIA: corrección en la comida no aplicada”. Si la rectificación de carbohidratos es aplicable, entonces, se presenta uno de los siguientes mensajes emergentes (dependiendo de las cantidades introducidas): “ADVERTENCIA: La comida de (cantidad en número) gramos introducida en (hh:mm) se corrige ahora a (cantidad en número) gramos. ADVERTENCIA: La comida restante debe estar entre (cantidad en número) y (cantidad en número) gramos”.

Anulación de la insulina

Después del módulo de rectificación de carbohidratos 834, el EA 518 llama al módulo de anulación de la insulina 836. Como se menciona anteriormente, el módulo de anulación de la insulina 836 niega los componentes de la insulina de prealimentación de la insulina administrada final, es decir, la cantidad de insulina distribuida para el ciclo. La administración de insulina final es todas las cantidades de insulina que proceden de todos los módulos de prealimentación de EA, tales como, por ejemplo, la solicitud de inyección intravenosa rápida automática, la inyección intravenosa rápida relacionada con la comida y el componente de retroalimentación. La anulación de la insulina elimina cualquier cantidad de insulina de prealimentación de la administración de insulina final. La implementación actual de EA 518 controla diversos componentes de la insulina de prealimentación por separado. La anulación de la insulina implica en realidad que se han eliminado todas las cantidades de insulina de prealimentación. Para obtener recomendaciones de retroalimentación de insulina correctas, es imperativo que todos los componentes de prealimentación se eliminen correctamente.

I

El vector de insulina anulada, ^ viene dado por la ecuación (16):

i L I 1

V 1 - ! , - ! < (16),

donde ¡ es un vector de insulina administrada, ^ es una inyección intravenosa rápida relacionada con la comida y

1

de intervención de alto contenido de glucosa, ^ son inyecciones intravenosas rápidas relacionadas con el componente de prealimentación de inyección intravenosa rápida automática y cebado. Obsérvese que si los valores anteriores no están disponibles en los datos de administración por la bomba, entonces la información anterior se completará con dosis de insulina basal.

Predicción de glucosa y acción de control basal

Luego, el EA 518 llama al módulo de predicción de glucosa 838. Las mediciones de glucosa obtenidas por APTS son mediciones con retardo porque el sensor tiene retrasos físicos y en el procedimiento. La predicción de glucosa exacta en el futuro es una clave para proporcionar un control glucémico. El módulo de predicción de glucosa 838 realiza predicciones usando información de administración de insulina anterior, las mediciones de glucosa y el uso de la farmacodinámica de la insulina. La FIG. 17 muestra la farmacodinámica de la insulina restante. Para la implementación, la farmacodinámica de la insulina restante para una inyección intravenosa rápida unitaria se define

1

en el archivo subject.ini y se proporciona aquí por O Como se muestra, la farmacodinámica para la respuesta al impulso de insulina unitaria se muestrea a Tc= 10 min.

La parte basal del controlador basal 628 se basa en principios similares a los usados en la predicción de glucosa. El principio subyacente es que los cambios de los niveles de glucosa se deben a perturbaciones de la planta no modeladas que corrige el controlador basal 628 (FIG. 6). Los ajustes a las inyecciones intravenosas rápidas de insulina tienen en consideración la glucosa predicha. Las salidas de datos del predictor de glucosa 626 y el punto fijo 603, que, en conjunto, proporcionan el control basal forman la parte de retroalimentación del controlador basal 628. En resumen, el cómputo de la recomendación de retroalimentación de bucle cerrado requiere (a) un valor de glucosa predicha reciente y (b) un historial de insulina administrada.

Para predecir la glucosa en una hora actual, el módulo de predicción de glucosa 838 usa la siguiente información.

1 Valor de glucosa procesada, G[K] y el tiempo procesado correspondiente, íg[K]. Información de insulina anulada, /[. n:-ii/] durante los últimos minutos T^d con respecto a j, donde T^d es la duración del efecto de la insulina. Si Te es el

periodo de control, entonces, To=nTc. Obtener la farmacodinámica de la insulina, 1. Se supone que la caída de glucosa es directamente proporcional a la insulina utilizada, AGjijrc A/r[/'] donde / = 1, 2, ..., n. Se obtiene la insulina 1 1 utilizada O para una inyección intravenosa rápida unitaria como la diferencia progresiva realizada sobre el vector ^

I

. El vector ^ r viene dado por la ecuación (17):

AOIW j+lJ 0*1® ,2...* 1 ^(17),

La FIG. 18 muestra gráficamente los cambios en la insulina utilizada ^A '■ para una inyección intravenosa rápida unitaria a lo largo del tiempo. Si la constante de proporcionalidad es Ki, sensibilidad a la insulina [mg/dl/U], entonces, la caída de glucosa debida a la utilización de la insulina se define por la ecuación (18) como:

A<7f/J--A :.A /r [ í j <10),

El vector de caída de glucosa se define por la ecuación (19) como:

AC- K, £¡Jr (19).

Para predecir la caída de glucosa en el momento j, dado que la medición de glucosa más reciente G[K], donde K es la hora para la que el valor de glucosa está disponible actualmente, viene dada por la convolución del vector de ■^{i i}

ine por la ecuación (20) como:

donde /[.n:-in es el vector de las últimas cantidades de insulina administradas n con respecto al punto j, la caída de glucosa, AG j] en el instante jésimo, donde j = K + 1, ..., k ciclo. La FIG. 19 muestra gráficamente la predicción de impulso de insulina. El módulo de predicción de glucosa 838 usa la ecuación (20) para predecir la glucosa por un instante j. La predicción para la glucosa en k se realiza pasando j de K + 1 a k. La predicción de glucosa se computa a partir de 3 partes: (a) insulina basal administrada, (b) insulina basal definida previamente y (c) predicción de glucosa.

(a) Insulina basal administrada

.

El vector de insulina basal administrada 'b'¡ es la administración de insulina anulada. La caída de glucosa esperada, AGⁿ[/] se define por la ecuación (21) como:

(b) Insulina basal definida previamente

La insulina basal definida previamente se determina a partir del conjunto basal y es el valor de “insulina basal actual”, } s

f "■ 4 con una situación sin perturbaciones. Este es el componente de la insulina basal requerido para mantener la glucosa objetivo, Gt. La caída de glucosa esperada, AGb viene dada por el producto interior definido por la ecuación (22) como:

(c) Predicción de glucosa

Entonces, dado el valor de glucosa G j] en la jésima etapa, entonces la glucosa predicha G[j +1] viene dada por la ecuación (23) como:

Donde, AGPj +1]] es la subida de glucosa estimada de una perturbación conocida. La predicción de glucosa se transfiere desde el último valor de glucosa conocido en el tiempo tK con respecto a la hora actual, tk. Entonces, el EA 518 procede al módulo de compensador de comidas 840.

Compensador de comidas

El módulo de compensador de comidas 840, cuando se llama, aborda la ingesta de carbohidratos. Las proteínas y grasas se convierten en una cantidad equivalente de carbohidratos. El tipo de comida está asociado con la hora del día, así como con el tamaño de la ingesta de carbohidratos. Las definiciones de los diversos tipos de comida se enumeran en la tabla 5.

Tabla 5: Definición del tipo de comida

Se reconoce que uno de los factores que afectan la tasa de absorción de glucosa intestinal (es decir, la velocidad de la comida) es la composición de la comida. Implícita a la selección de la cantidad de comida, se tiene cuenta la velocidad de la comida. En un ciclo de control, si se desencadenan múltiples acontecimientos de comida, entonces, EA 518 considera solo la entrada de la última comida. Las inyecciones intravenosas rápidas de insulina distribuida para cubrir la comida se describen en la sección de implementación. Una comida abundante no es necesariamente equivalente a la suma de varias comidas pequeñas. Esto se puede definir en una pauta de comidas, por ejemplo, comida pequeña = 25 g, comida regular = 50 g y comida abundante = 75 g. Si la petición de insulina basal actual es relativa y se ha activado una comida, entonces, el punto fijo se ajusta usando un perfil de carbohidratos rápidos. Se espera que la glucosa aumente rápidamente debido a la subida de la comida con dinámicas como carbohidratos rápidos, no lentamente como la farmacodinámica de la insulina.

Aviso de comidas

Luego, el EA 518 llama al módulo de aviso de comidas 842, si procede, para proporcionar un cuadro de diálogo emergente que informa al sujeto para que comience a comer. Si se ha de presentar una ventana emergente de aviso de comidas, entonces, se fija una marca que controla el módulo de aviso de comidas 842 por el controlador basal 628. Control interno de inyecciones intravenosas rápidas

Adicionalmente, si procede, el EA 518 llama al control interno de inyecciones intravenosas rápidas 844 para administrar las inyecciones intravenosas rápidas que resultan de un acontecimiento de comida.

Recomendación de insulina

Posteriormente, el EA 518 llama al módulo de recomendación de insulina 846 para computar una dosis de insulina usando el valor de glucosa predicha actual como se describe anteriormente. En particular, la recomendación de insulina para una dosis de insulina se computa proyectando los efectos de la insulina a bordo, la futura introducción basal y los efectos de otros acontecimientos introducidos. Las siguientes etapas determinan la recomendación de insulina basal: (a) glucosa actual, (b) insulina de perturbación basal administrada, (c) punto fijo de glucosa, (d) insulina basal definida previamente y (e) subida de glucosa.

(a) Glucosa actual

La glucosa actual se determina a partir de la sección de glucosa de predicción y viene dada por G[k].

(b) Insulina de perturbación basal administrada

Este vector f *' es la administración de insulina anulada. Entonces, la insulina estimada restante es [k] y viene dada por la ecuación (24) como:

(c) Punto fijo de glucosa

Esta es la glucosa objetivo y dada por Gt.

(d) Insulina basal definida previamente

I ,v

Esto se determina a partir del conjunto basal y es el valor de “insulina basal actual”, * . Este es el componente de la j s

insulina basal requerido para mantener la glucosa objetivo, Gt. La insulina esperada restante, r [k] viene dada por el producto interior definido por la ecuación (25) como:

(e) Subida de glucosa

La subida de glucosa viene dada por AGp. En consecuencia, la recomendación de insulina, entonces, viene dada por Ireq como se define por la ecuación (26) como:

(26),

donde la Gestimada viene dada por la ecuación (27) como:

W Q [ * ] [ - * / ( # t * J - ' , " [ * ] ) > a g > (21 ),

y se determina teniendo en cuenta las etapas (a) hasta (e).

Los siguientes casos que modifican la recomendación de insulina son que la glucosa satisface la zona objetivo y un requerimiento basal mínimo. Como se menciona anteriormente en una sección previa, la zona objetivo (es decir, objetivo 601) se define como una región fija que tiene un intervalo de puntos fijos inferiores y superiores en lugar de *-,Lo

, , , , . .. jr'1 y tJí define los puntos fijos superiores e inferiores, respectivamente. Si la estimación de la glucosa Gestimada está en la zona objetivo, entonces, Ireq simplemente es insulina basal. Para el caso de requerimiento basal mínimo, cuando Ireq es negativo, el EA 518 ha predicho que el sujeto está actualmente en un estado de administración de insulina en exceso. Una tasa basal mínima (típicamente la mitad de la tasa basal) se implementa por el ALGO 510 durante dichas circunstancias administración en exceso. Es importante que las concentraciones de insulina circulante nunca disminuyan por debajo de un valor umbral para evitar la contrarregulación. La aplicación del mínimo basal garantiza niveles de insulina circulante mínimos.

Depósito de insulina

Cuando el EA 518 llama al módulo de depósito de insulina 848, se realiza una recomendación de insulina final a partir de la combinación del control basal y los requerimientos de insulina de bucle abierto debido a diversos acontecimientos desencadenados. Adicionalmente, existen limitaciones impuestas a las recomendaciones de insulina final, tales como, por ejemplo, un límite en la cantidad de insulina para cada ciclo de control, que se llama la limitación del tope de administración. Finalmente, la recomendación de insulina puede no implementarse. Por ejemplo, el profesional sanitario es la autoridad final de aceptación o rechazo de una recomendación. La administración de insulina final es la administración real. Por lo tanto, los componentes de mantenimiento de registros de insulina, que se mantienen en los diversos depósitos de insulina, se deben ajustar a las limitaciones de recomendación. Si la recomendación de insulina final difiere de la administración de insulina final, entonces, en consecuencia, ALGO 510 evalúa de nuevo y contabiliza de nuevo los componentes con respecto a la administración de insulina final revisada.

En el punto del procedimiento 850, el EA 518 determina si el control puro 600 de bucle abierto está habilitado, si se fija la marca de que no hay suficientes mediciones de bG (que es el punto de entrada de nuevo desde el punto del procedimiento 816), o si se fija la marca de bG desactualizada. Si alguna de estas condiciones es falsa, entonces, el EA 518 llama al módulo de actualizar almacenamiento 854 para guardar el valor y las condiciones de este ciclo de control. Si cualquiera de las condiciones es cierta, entonces, el EA 518 llamará al módulo de gestión de discrepancias 818, al modelo de inyección intravenosa rápida de solicitud 830, al módulo de intervención de alto contenido de bG 832 y al módulo de limitación del tope de administración 852 que impone limitaciones a las recomendaciones de insulina final. Al finalizar estas llamadas, entonces, el EA 518 llamará al módulo de actualizar almacenamiento 854 para guardar el valor y las condiciones de este ciclo de control. Entonces, el EA 518 espera hasta el inicio del próximo ciclo de control del ALGO 510 antes de reiniciar el flujo del procedimiento mostrado mediante las FIGS. 8 y 9 y descrito anteriormente.

ALGOSHELL

ALGOSHELL 506 proporciona la gestión de la estructura de datos y macros relacionadas que se localiza en una carpeta del sistema. En particular, ALGOSHELL 506 es una función que genera salidas de datos con respecto a introducciones de datos dadas llamadas desde APS 500. La función ALGOSHELL 506 también funciona con el APSe que se ejecuta en el entorno de simulación (Simulink). Como se menciona anteriormente, el entorno del banco de pruebas APS no es un entorno Simulink, donde APSe es una función de envoltorio que simula el entorno del banco de pruebas APS. ALGOSHELL 506 interactúa con APS, el banco de pruebas en tiempo real, y APSe en un entorno simulado. La llamada del ALGOSHELL 506 estandarizada es como sigue: [yAMT, yAdvice, yTrace, xk'] = ALGOSHELL _ xxx (t, xk u, EventStruc, ExperimentStruc, PumpStruc, BGStruc, PatientIniStruc). La FIG. 33 muestra cuándo se actualizarán las variables con respecto a ALGO 510. Las variables de introducción de datos t, xk u, EventStruc, ExperimentStruc, PumpStruc, BGStruc, PatientIniStruc de la llamada del ALGOSHELL 506 se analizan en primer lugar en lo sucesivo, seguido de las variables de salida de datos yAMT, yAdvice, yT race y xk'.

Variables de introducción de datos

El término t es un escalar de tiempo para el tiempo transcurrido o de la simulación. Se espera que el tiempo t sea un múltiplo del tiempo TControl /- delta para la llamada Sync1 y se define como el límite del ciclo de control actual. La llamada Sync2 seguirá a Sync1 y se producirá antes del próximo límite del ciclo de control. El término xk es un vector de estado que contiene un conjunto de variables requeridas por ALGOSHELL denominadas estados. En APSe, estos son los estados discretos mantenidos por los controles que actualizan los estados discretos. Cuando se llama al APSe, xk está disponible como estados. Por otra parte, el APS siempre está en control y es responsable de mantener xk. La longitud y las características específicas del vector xk son dependientes de ALGO. El APS no necesita conocer la longitud o las características específicas de xk. La variable xk se debe inicializar en la matriz vacía [ ] por el APS. Entonces, ALGOSHELL 506 determinará su longitud correcta la primera vez que se llame. A partir de entonces, el experimento debe mantener la longitud de xk. APS/APSe no debe modificar los valores o la longitud de xk. El término u es el vector de introducción de datos y consiste en la salida de información por los dispositivos de campo, es decir, la bomba y los sensores. Tanto APS como APSe necesitan conocer los detalles del vector de introducción de datos, u. Ver la tabla 6 para obtener más detalles. Obsérvese que "insulina distribuida neta" es un contador acumulativo para la cantidad total de insulina distribuida por una bomba.

Tabla 6: Vector de introducción de datos, u

EventStruc - Estructura del acontecimiento

Esta es una estructura que contiene la programación de activación predefinido. Está disponible para APSe como uno de los parámetros. APS, por otra parte, obtiene la programación y actualiza EventStruc a partir de los acontecimientos desencadenados a partir de la ventana principal de APS 902. Ver la tabla 7 para los campos de la estructura del acontecimiento.

Tabla 7: Campos EventStruc

El campo PatientIniStruc.events.units proporcionado en la tabla 7 es una matriz de unidades de acontecimientos que se presenta por las GUI de APS. Cada uno de los campos en EventStruc es una matriz de columnas. Todas las matrices de columnas serán de la misma longitud. Si una fila particular no tiene información, se introducirá NaN y se mantendrán las longitudes de las filas. En APS, se actualiza EventStruc cuando se registra un acontecimiento. En APSe, EventStruc existe previamente. Todos los acontecimientos se programan antes de ejecutarse. En esencia, no existe diferencia en la implementación. ALGOSHELL 506 solo ve los acontecimientos registrados que son menores o iguales que tiempo de la simulación actual. Al menos uno del tiempo de activación o de respuesta del controlador tiene que ser distinto de cero para que ALGO 510 acepte el acontecimiento como un acontecimiento significativo. Si no se introduce ninguno de los dos tiempos, ALGO 510 no puede juzgar cuándo se produjo ese acontecimiento particular y lo ignorará. Las entradas de tipo acontecimiento son las enumeradas por la estructura de “patientini.events” y tienen los campos de tipo, unidades e InternalName. Pueden variar de un experimento a experimento. Los acontecimientos son de dos clases: acontecimientos que se usan solo para propósitos de registro solo para, por ejemplo, un acontecimiento de extracción de sangre; y acontecimientos que informan a ALGO 510 para que tenga en consideración y reaccione apropiadamente a un acontecimiento, por ejemplo, el desayuno.

ExperimentStruc - Estructura del experimento

Esta es una estructura que está predefinida y disponible para APSe por medio de parámetros de APSe. APS carga la estructura del experimento para una ejecución del experimento. Ver la tabla 8 para los campos de la estructura del experimento.

Tabla 8: Campos de la estructura del experimento

PumpStruc - Estructura de la bomba

Excepto por los campos de datos, todos los campos de esta estructura están predefinidos y se obtienen de las interfaces de usuario de APCATS 900. Esta estructura se envía inicialmente como un parámetro. En la fase de inicialización, PumpStruc se convierte en un archivo mat. APS tiene una configuración similar. Como se usa en el presente documento en la tabla 9, "fuera de línea" significa la condición que se produce cuando la bomba no está disponible según la última información de estado de APSCOM 504. Ver la tabla 9 para los campos de la estructura de la bomba.

Tabla 9: Campos PumpStruc

BGStruc - Estructura de la glucosa en sangre

Excepto por los campos de datos: bgldata y bgltimestamp, todos los campos de esta estructura están predefinidos y se obtienen de la interfaz de usuario de APCATS 900. Esta estructura se envía inicialmente como un parámetro. Los sensores están numerados como 0, 1, 2, 3... con el Sensor 1 considerado como el sensor virtual. La tabla 10 muestra los campos de la estructura del sensor para el sensor 1. Para otros números del sensor, el “1” en cada uno de los campos se reemplaza por el número del sensor. Se admiten hasta 4 sensores: 2 SU, 1 sensor externo y 1 virtual. Sin embargo, para APS-3, se tiene el siguiente mapeo para sensores: 0 para “EXT”; 1 para “SU 1”; y 2 para “SU 2”.

Tabla 10: Campos de la estructura del sensor

Simplemente seguir la llamada de ALGO, y APS/APSe actualiza los campos BGStruc.

PatientIniStruc - Estructura de inicialización del paciente

Esta estructura se define en un archivo de inicialización (archivo INI) e incluye vectores de respuesta específicos del paciente con respecto a la ingesta de comidas y a la degradación de la insulina. El archivo INI proporciona parámetros específicos del estudio y específicos del sujeto con respecto al APTS 500 y ALGO 510. El archivo INI del sujeto se carga cuando se activa el APS que contiene datos específicos del sujeto, incluyendo parámetros de algoritmo, confirmación automática de dosis única y tres umbrales de confirmación de dosis y tipos de acontecimiento. Los tipos de acontecimiento como se explica anteriormente son actividades que se pueden seleccionar manualmente por el profesional sanitario durante el experimento a través de una lista desplegable. Los tipos de acontecimiento comunes incluyen comidas y lecturas del medidor de glucosa en sangre (bG) externo. Los valores de la lista desplegable se determinan por el archivo INI del sujeto. El umbral de dosis consecutivas, como se designa en el archivo INI del sujeto, es la cantidad máxima de insulina que se ha de administrar en tres ciclos sucesivos sin la aprobación del profesional sanitario. El umbral de confirmación automática, como se designa en el archivo INI del sujeto, es la cantidad máxima de insulina que se ha de administrar en un único ciclo sin la aprobación del profesional sanitario. Experimentales son los datos obtenidos desde el principio al fin del APTS, incluyendo cualquier reinicio intermedio y cambio de los archivos INI. Ver la tabla 11 para las descripciones del campo proporcionado en el archivo INI del sujeto.

Tabla 11: Campos PatientIniStruc

Variables de salida de datos

El término yAMT es un vector de solicitud para la bomba y presentación, y contiene solicitudes para la bomba. La tabla 12 proporciona detalles sobre las recomendaciones contenidas en el vector de solicitud yAMT.

Tabla 12: vector yAMT

El término yAdvice es una cadena de avisos que proporciona advertencias y otras posibles medidas de protección en caso de fallo marcadas por ALGO, pero implementadas por APS. La cadena yAdvisory está compuesta por un número de aviso de dos dígitos, seguido de un espacio, seguido de una instrucción. Los números de aviso se dividen en tres categorías: (1) Nominal (intervalo: 00 a 09), (2) abrir una ventana de mensaje (intervalo: 10 a 98) y (3) salir/abandonar (intervalo 99). El término yTrace es una cadena de verificación que verifica las etapas de la ejecución de ALGO. El progreso de ALGO se registra en un archivo log localizado en la DataPath definida en el archivo ExperimentStruc. xk' es un vector de estado que se necesita para el inicio de ALGO en la próxima llamada de ALGO.

Interrupción del ciclo de control

Para el modo de recomendación, que incluye llamadas sincronizadas, la ventana de confirmación por el usuario y las llamadas asincronizadas, cada valor solicitado se limita a la cantidad que la bomba puede distribuir en la porción restante del periodo de control. La ventana de confirmación es un cuadro de diálogo que requiere la confirmación final de la insulina solicitada y aparece cuando el profesional sanitario acepta o rechaza manualmente una recomendación de insulina. En un modo de realización ilustrado, expira el tiempo de esta ventana después de 45 segundos. Como tal, el periodo de control se divide en tres regiones como se muestra mediante la FIG. 34, y los parámetros en ALGOSHELL se enumeran en la tabla 13. Cada ciclo de control en un caso ideal permitirá que se llame a ALGO al inicio del ciclo de control. ALGO procesará la introducción de datos y recomendará una cantidad que se ha de dispensar en la parte restante del ciclo de control. Pero existen limitaciones al equipo físico porque (1) cada acción dura un tiempo finito y (2) el reloj interno es discreto. Además, existe una intervención humana y, para el control de bucle abierto, existe variabilidad en el tiempo real que queda para la acción de control. Después de tener en cuenta todas estas consideraciones, se determina un valor solicitado que permitirá la administración de la solicitud en total.

Tabla 13: Parámetros en ALGOSHELL

Todos los bloques blancos indican que la variable incluida está actualizada. La FIG. 33 se ve desde el punto de vista del APS. Los datos de introducción se muestran antes y después de la llamada “Syncl”.

Situación de recomendación pura

Si m es la última llamada de ALGOSHELL 506 en control, entre la mésima y (m+1).a llamada, BGStruc se actualiza con las nuevas mediciones. Estas mediciones se obtienen de la base de datos. Antes de m+1.er ALGO 510 llama a los siguientes: (a) la medición de BG más reciente (última) y la hora, así como el estado del sensor de BGStruc que se asignan al vector u; (b) la información sobre la última insulina neta distribuida que se obtiene a partir de la base de datos y se asigna al vector u; (c) la hora t, que se fija en la hora a la que se llama a ALGOSHELL 506; (d) el vector xk se pasa por APS como tal; y (e) el modo de bomba del experimento se fija en 3. Se llama de nuevo a ALGO 510, n=m+1. Se llama a ALGOSHELL 506 con el modo = 3, es decir, como una llamada Sync1.

Para la llamada Sync1, se devuelven el vector yAMT y otros argumentos de salida de datos. APS realiza una actualización mostrada en la FIG. 35 usando yAMT. Se analiza yAdvisory se presentan mensajes apropiados (enviando a la ventana de registro, abriendo un cuadro de mensaje y saliendo). La cantidad recomendada yAMT(4) se presenta en la ventana de recomendación 514 de APS (FIG. 5). La ventana de recomendación 514 presenta la dosis de insulina recomendada para el ciclo actual, como se determina por el ALGO 510. La ventana de recomendación 514 aparece al final de un ciclo de ejecución con la cantidad recomendada de insulina que se ha de infundir. Si la cantidad está en el umbral de una o tres dosis, no se necesita confirmar por el profesional sanitario. Se obtiene una respuesta del usuario que es: (a) recomendación rechazada, VALOR=0, indx=0; (b) recomendación aceptada (confirmación), VALOR=yAMT(4), indx=1; o (c) ignorar, VALOR=EnterValue, indx=2). Se actualiza el vector pumpdat. Se realizan las siguientes asignaciones como se muestra mediante la FIG. 35: para la actualización de pumpdat, u elementos relacionados con el sensor son ceros; u(1) a través de u(6) son NaN, y se asigna VALOR a u(7); u(8) es la hora actual t; y u(9) es la marca del estado de la bomba. El modo del experimento se fija en 4 (para la llamada Sync2). Se llama de nuevo a ALGO 510, n=m+2. Finalmente, se realiza una llamada a ALGO 510 como una llamada Sync2. Para Sync2, el vector Pumpdat se actualiza como se muestra mediante la FIG. 35. Entonces, se repite la secuencia para el próximo ciclo de control.

Flujo de ALGO-APS

Un ejemplo del flujo del procedimiento de ALGO-APS también se proporciona en lo sucesivo en la tabla 14. Se ha de observar que el tiempo transcurrido es la hora relativa t en minutos desde el inicio del experimento. Cuando se produce un reinicio, el tiempo de inicio es el tiempo de inicio del experimento y no el tiempo de inicio del reinicio. El tiempo transcurrido sigue siendo el relativo medido con referencia a “ExperimentsStruc.t_zero”.

Tabla 14: Flujo de ALGO-APS

Algunos aspectos de interés son que Syncl sigue a Sync2 siempre que Sync2 ocurra antes del límite del ControlCyle, y el reinicio de yAMT se registra y almacena correctamente por APS. Se ha de observar que el reinicio es la reanudación de un experimento no terminado con los datos previos obtenidos para que APTS los muestre en gráficos y para que ALGO los use. Los datos del sensor y la bomba se asignan a BGStruc y PumStruc usando el tiempo transcurrido en minutos. El vector u siempre envía los datos disponibles más recientes junto con el registro del tiempo. Si no se adquieren nuevos datos, entonces, los últimos datos conocidos adquiridos. Ahora se proporciona un análisis sobre el segundo modo de realización de implementación de la especificación.

APCATS (paquete de pruebas con algoritmo de control para páncreas automatizado)

El paquete de pruebas con algoritmo de control para páncreas automatizado (APCATS) es un programa informático que sirve como una herramienta de simulación estandarizada, un emulador de banco de pruebas para AP, una herramienta de verificación y como una herramienta de evaluación. Como herramienta de simulación estandarizada, APCATS proporciona la funcionalidad básica necesaria para simular un sistema de bucle cerrado genérico. Como tal, esta funcionalidad permite que alguien que diseña modelos matemáticos se centre en el propio modelado, en lugar de en los detalles de las conexiones y la verificación de la configuración básica y las conexiones. Como un emulador de banco de pruebas para AP, el programa puede acortar el tiempo requerido para evaluar y verificar los cambios del algoritmo a partir de lo que se requeriría por el APTS 500. Para lograr esto, usa el tiempo “simulado” (a diferencia del tiempo real) mientras que proporciona el mismo entorno simulado para el ALGO 510. Además, permitiendo la simulación en un intervalo de valores paramétricos, APCATS puede ampliar el alcance de una evaluación sin poner en peligro al paciente. Además, se puede usar APCATS para simular y evaluar situaciones críticas. Por ejemplo, los fallos de los dispositivos se pueden evaluar sistemáticamente o se pueden implementar y evaluar modos de protección en caso de fallo.

Como herramienta de verificación, APCATS proporciona la capacidad de emular un APTS 500, de este modo permite que cualquier revisión con respecto al ALGO 510 se verifique por primera vez en las situaciones de desarrollo y publicación previa. Como herramienta de evaluación, se puede usar APCATS para simular modelos matemáticos, controladores, respuestas de bucle cerrado, etc., permitiendo, por tanto, que se evalúen (1) la calidad y (2) el rendimiento del elemento simulado. En el modo de realización ilustrado, se desarrolló APCATS y se ejecuta en el entorno de computación técnico de MATLAB. En otros modos de realización, se pueden usar otros lenguajes y entornos de computación, tales como visual basic y el sistema operativo Windows. La interfaz de usuario de sección de entrada proporciona un medio rápido de desarrollo y análisis de las leyes de control para el sistema de páncreas automatizado un tanto estandarizado. Proporciona una plataforma común para realizar un análisis y simulaciones, así como para manejar un sistema real, si el equipo físico está conectado en el bucle de control. Ya que se implementa el APCATS en un entorno operativo similar al APTS 500, tal como en el sistema 10, y la implementación de un programa informático en un equipo físico se entiende bien por los expertos en la técnica, las secciones en lo sucesivo solo se centran en los componentes de programa informático de este segundo modo de realización de implementación de la especificación de la presente invención.

Componentes de programa informático

La aplicación de APCATS comprende distintos componentes de programa informático que se dividen en tres categorías: interfaces de usuario; archivos de inicialización; y módulos de componentes. El APCATS tiene un núcleo central que contiene los datos y forma la base que reúne a todas las secciones de entrada en una aplicación unificada. Los archivos de inicialización, también denominados archivos init, informan al núcleo del APCATS sobre dónde están los módulos necesarios y sobre qué módulos necesita leer e implementar. En base a la información en estos archivos, se crea dinámicamente el APCATS por sí mismo. Los módulos de componentes describen matemáticamente cómo se comporta cada uno de los componentes. Durante la simulación, reaccionan dinámicamente a las excitaciones externas e internas. Los módulos de componentes se clasifican en el presente documento en los siguientes tipos principales: planta; activador; sensor; controlador; y perturbaciones externas. Cada uno de estos módulos de componentes se analiza con mayor detalle en secciones posteriores.

La interfaz de usuario (UI) es la sección de entrada que permite la introducción de datos del usuario, tal como: selección de opciones, interacción con determinados rasgos característicos e introducción o modificación de valores. También permite al usuario observar los datos de salida. Debido a que el núcleo está diseñado para ser independiente del problema por sí mismo, la definición del problema se encuentra en los módulos de componentes. La flexibilidad de la interacción entre la UI y los módulos de componentes se controla a través de los archivos de inicialización. La interfaz de usuario cubre los siguientes aspectos principales: ventana principal del APCATS; formularios de entrada de usuario para cada componente; formularios de menú para componentes; formulario de configuración de ejecuciones de simulación; generación de diagramas de bloques de enlace de simulación (Simulink); gestionar e interactuar con archivos de datos; gráficas para presentar resultados; almacenamiento y recuperación de la configuración de APCATS; e interfaz de conexión.

Con referencia a la FIG. 22, APCATS, en general, indicado por el símbolo 900, proporciona una interfaz de usuario como ventana principal 902. La ventana principal 902 proporciona tres paneles: un panel ejecutar/almacenar 904; el panel de algoritmo 906; y el panel de gráficas 908. Además, una barra de estado 910 en la parte inferior transmite mensajes de la actividad de APCATS 900.

El panel de algoritmo 906 es un algoritmo de control que es fundamental para regular el nivel de glucosa en sangre en un paciente modelo. El panel de algoritmo 906 presenta el algoritmo de control para páncreas automatizado, que consiste en varios bloques conectados con líneas de conexión de entrada/salida X. El panel de algoritmo 906 se usa para configurar el sistema de bucle cerrado global.

Permite seleccionar modelos, editar valores de parámetro y modificar conexiones. Cada uno de los bloques y conexiones se puede seleccionar para presentar y fijar sus parámetros. Los bloques disponibles son: bloque de perturbaciones externas 912; bloque de planta 914; bloque de sensor 916; bloque de controlador 918; y bloque de activador 920. Como se muestra, las conexiones de bloques son: conexión de bloque de perturbaciones externas/bloque de planta; conexión de bloque de planta/bloque de sensor; conexión de bloque de sensor/bloque de controlador; conexión de bloque de controlador/bloque de activador; conexión de bloque de activador/bloque de planta; y conexión de bloque de activador/bloque de controlador.

La FIG. 23 es un diagrama de bloques que muestra la estructura de bucle cerrado genérica en la que las flechas de interconexión en el diagrama representan las interfaces entre los bloques del panel de algoritmo 906. Las flechas de interconexión también representan el flujo de información entre los bloques. Cada uno de los bloques del panel de algoritmo 906 proporciona, en la capa superior, varias opciones al usuario. Otras opciones, si hay alguna, asociadas con una selección se presentan como subcapas ocultas. Estas capas se abren al usuario y se activan a medida que el usuario pasa de la capa superior visible a las más bajas. A través de los diversos bloques 912-920 y las conexiones en el panel del algoritmo 906, es posible modificar los parámetros necesarios para la simulación. Permiten al usuario seleccionar entre varios modelos posibles; fijar los parámetros correspondientes a los modelos seleccionados; y fijar la información que se envía a través de las conexiones de entrada/salida. Los diversos bloques del panel de algoritmo 906 se describen con más detalle en lo sucesivo, con referencia hecha en primer lugar al bloque de planta.

Bloque de planta

El bloque de planta 914 proporciona una lista de una serie de modelos de paciente seleccionables (por ejemplo, los modelos de paciente 73 en la FIG. 3) que refleja el conocimiento actual de la fisiología pertinente y las interacciones metabólicas. Los nuevos modelos de paciente con grados variables de complejidad y detalle se pueden modelar y proporcionar (añadir) para su uso en el bloque de planta 914. Ajustando los límites de los parámetros, se puede usar el bloque de planta 914 para estudiar y modelar una amplia variedad de comportamientos. El bloque de planta 914 recibe una introducción de datos de los activadores y perturbaciones creadas por diversas ingestas dietéticas. Los sensores se usan para medir las salidas de datos del modelo de paciente seleccionado en el bloque de planta 914.

Selección de planta y configuración de parámetros

El modelo de paciente se selecciona a través del bloque de planta 914 haciendo clic en uno de los botones de radio correspondientes. Solo se puede seleccionar un solo modelo de paciente en cualquier momento. El botón de radio correspondiente aparece resaltado y aparece una ventana de menú de planta 922 como se muestra mediante la FIG.

24. Haciendo clic en un modelo de paciente ya seleccionado también se abrirá la ventana de menú de planta 922. Si la ventana de menú de planta 922 ya está abierta cuando se selecciona una nueva planta, APCATS 900 comprobará para ver si se han guardado los parámetros introducidos en ella. Si lo han sido, la ventana de menú de planta 922 actual se cerrará y se abre una nueva ventana de menú de planta para el modelo recién seleccionado. Si los parámetros no se han guardado, se presentará un mensaje a tal efecto en la barra de mensajes en la parte inferior de la ventana principal 902 y la ventana de menú de planta 922 ya activa no se cerrará. Los parámetros correspondientes al modelo de paciente seleccionado se presentan en la ventana y se cargan con valores guardados almacenados en la memoria. Los valores de parámetro se pueden editar y se presentarán en los siguientes colores que indican su estado de edición: negro —valor predeterminado o no editado— ; rojo —valor editado— ; azul —valor no editable bloqueado— .

Si se cambia la selección del modelo de paciente, se interrumpirán las conexiones existentes previamente entre los bloques vinculados con el bloque de planta 914 y el usuario necesitará conectarlos de nuevo. (Ver la sección de conexiones proporcionada a continuación). Las introducciones de datos y salidas de datos asociadas con el bloque de planta 914 se actualizan. Además, seleccionar un nuevo modelo de paciente dará como resultado una lista actualizada de variables independientes y dependientes en la configuración de gráfica. (Ver la sección 6). Cada parámetro en la ventana de menú de planta 922 se enumera en su propia fila. Las columnas en la ventana de menú de planta 922 son: una columna de “n.os” 924 para cada fila, una columna de "parámetro" 926 para los nombres de los parámetros y una columna de "editar valor" 928 para introducir un valor de parámetro. El valor introducido debe estar entre los valores mínimos y máximos especificados para el parámetro en las dos columnas proporcionadas después de una columna de “valor de control deslizante” 930, donde los cambios en el valor también se reflejarán en el control deslizante 932 adyacente.

La columna "valor de control deslizante" 930 proporciona un procedimiento alternativo de fijación del valor del parámetro, correspondiendo los extremos izquierdo y derecho del control deslizante 932, respectivamente, a los valores mínimos y máximos para el parámetro. Cuando se mueve el control deslizante 932, el valor numérico del parámetro se actualizará en la columna a la izquierda del control deslizante en la columna editar valor. Una columna “editar mín.” 934 proporciona el valor de parámetro mínimo permitido. Este valor se puede editar, donde los cambios también se reflejarán en el control deslizante 932. Una columna “editar máx.” 936 proporciona el límite superior del valor de parámetro. Se debe usar un valor grande para los parámetros que no tengan un límite superior. Este valor se puede editar, donde los cambios también se reflejarán en el control deslizante 932.

La columna de “n.° de div.” 938 se usa para indicar el número de valores del parámetro sobre el que se realizan las simulaciones (por ejemplo, estudios paramétricos). Se debe introducir un número entero positivo distinto de cero. Los valores distintos de números enteros se redondean al número entero válido más cercano. Para los siguientes valores de div, los valores de parámetro que se usarán en la simulación experimental son: 0 o 1 significa usar el valor de parámetro introducido; 2 significa usar los valores mínimos y máximos; 3 significa usar los valores mínimos, promedios y máximos; n (donde n es un número entero positivo) significa usar los valores intermedios igualmente espaciados n-2 mínimos, máximos. Obsérvese que los estudios paramétricos incluirán cada combinación de valores de parámetro y pueden dar lugar a un número de ejecuciones excesivo si se usan múltiples valores de varios parámetros. Para determinar el número de combinaciones, multiplicar los números de divisiones seleccionados para todos los parámetros. Con APCATS 900, se pueden realizar dos tipos diferentes de estudios paramétricos: (a) extensión sistemática del intervalo de parámetros; y (b) extensión aleatoria del intervalo de parámetros.

(a) Estudios paramétricos (sistemáticos)

Para realizar un estudio paramétrico sobre un parámetro dado, el usuario fija el número de divisiones para el parámetro con respecto al número de valores que se han de estudiar. Los valores de un parámetro para el que se realizarán ejecuciones serán el mínimo y máximo introducidos y un número de valores intermedios uniformemente espaciados suficientes para proporcionar el número de valores indicado. Por ejemplo, si el número de divisiones para un parámetro se fija en 5, se realizarán ejecuciones para los valores mínimos y máximos y otros tres valores, a %, A y % de la distancia entre el mínimo y el máximo. Si se fija que más de un parámetro use múltiples valores, se realizará una ejecución para cada combinación posible de los valores de todos los parámetros. Se debe tener precaución al fijar “n.os de div.”, ya que puede crear fácilmente un número excesivo de combinaciones/ejecuciones.

(b) Estudios paramétricos (aleatorios)

Para usar la selección de parámetros aleatorios, el usuario marca la casilla de comprobación “Seleccionar valores de parámetro de forma aleatoria” 940. Los campos “número de ejecuciones” e “ INICIADOR” 942 y 944, respectivamente, se habilitarán. En el campo “número de ejecuciones” 942, el usuario introduce el número de simulaciones que se han de ejecutar durante la simulación del experimento. En el campo “INICIADOR” 944, el usuario introduce un número entero positivo como iniciador para el generador de números aleatorios. El valor de INICIADOR se usa para recrear la secuencia de números aleatorios y se almacena en la documentación del experimento para permitir que los valores aleatorios se generen de nuevo. La generación de números aleatorios supone una distribución uniforme en el intervalo de parámetros. Para cada ejecución, los valores aleatorios usados para los parámetros se almacenan en el archivo de documentación. Un menú de línea de solicitud 946 en la parte inferior de la ventana de menú de planta 922 proporciona la siguiente funcionalidad: guardar, cancelar, ayuda y cerrar. “Guardar” guarda cualquier cambio de parámetros y solo está activo si al menos un valor ha cambiado desde la última vez que se guardó. "Cancelar" reestablece los últimos valores guardados. Este botón solo está activo si al menos un valor ha cambiado desde la última vez que se guardó. “Ayuda” abre una ventana de ayuda, y “cerrar” guarda los cambios, si hay alguno, y cierra la ventana 922.

Sensores y activadores

Debido a que las formulaciones de los bloques de sensor y activador 916 y 920, respectivamente, son similares, como lo son sus interfaces de usuario en el panel de algoritmo 906, se analizan en conjunto en el presente documento y se denominan colectivamente bloques del dispositivo. El bloque de activador 920 (FIG. 22) simula una unidad de bomba que recibe solicitudes del bloque de controlador 918. Esto activa el bloque de activador 920. La(s) salida(s) de datos del bloque de activador 920 se envían al bloque de planta 914. El bloque de sensor 916, por otra parte, mide las señales del modelo de paciente seleccionado en el bloque de planta 915 y envía información al bloque de controlador 918. Los bloques del dispositivo 916 y 920 tienen las siguientes características: dinámica del dispositivo que se describe por relaciones matemáticas, parámetros del dispositivo, introducción/introducciones de datos; y salida(s) de datos. Cada uno de los bloques de sensor y activador 916 y 920 proporciona las siguientes selecciones de configuración: número de dispositivos; tipo de dispositivo/modelo de dispositivo; y coeficientes del dispositivo. Obsérvese que, como el ruido y la no linealidad están integradas en las funciones, sus parámetros se pueden enumerar junto con otros coeficientes del dispositivo.

Los dispositivos se seleccionan de una lista desplegable 948 en los bloques del dispositivos 916 y 920 en el panel de algoritmo 906. Al seleccionar el dispositivo, los parámetros específicos para el dispositivo, también denominados coeficientes 950, se enumeran en el bloque del dispositivo respectivo. Los valores predeterminados se enumeran normalmente junto a la descripción del coeficiente. Los valores del coeficiente son editables. Si alguno de los valores se edita, los botones guardar y cancelar se activan. Para regresar a los últimos valores guardados, hacer clic en el botón cancelar. Para guardar los valores introducidos, hacer clic en el botón guardar. Cualquiera de estas acciones deshabilita los botones hasta que se realice la próxima edición. Obsérvese que las nuevas simulaciones no se ejecutarán si los botones guardar y cancelar están activos, es decir, si existen cualquier coeficiente no guardado en el bloque del dispositivo correspondiente. La capacidad de APCATS 900 para permitir que varias unidades de dispositivos se ejecuten en paralelo permite que se simulen simultáneamente múltiples sensores o bombas.

Para implementar múltiples unidades simultáneas, el usuario tiene que introducir el número deseado de unidades en la pestaña enumerada superior derecha 952 en el menú del dispositivo, que indica cuántos canales de control están en funcionamiento. Cada unidad tendrá su propia forma de dispositivo, seleccionable por una pestaña numerada 954 en la parte superior izquierda. La pestaña numerada 954 del dispositivo seleccionado actualmente se resaltará. El usuario puede editar los coeficientes 950 en cada uno de estos formularios. Un incremento del número de dispositivos añadirá nuevos dispositivos al final de la lista desplegable 948. Igualmente, una disminución eliminará los dispositivos del final de la lista 948 (es decir, los dispositivos número más alto). Si el usuario decide cambiar a otra pestaña antes de guardar el formulario, se le solicitará que guarde el formulario y debe guardar o cancelar las modificaciones antes de proceder. El usuario puede cambiar el número de pestañas y dispositivos en cualquier momento. Si introduce un número que excede un número máximo de dispositivos predefinido, el número regresará al valor anterior. Cada vez que se altera un dispositivo, se interrumpen las conexiones de introducción de datos y salida de datos existentes previamente para ese dispositivo. Antes de ejecutar una simulación, el usuario debe realizar nuevas conexiones entre el dispositivo y los módulos que suministran su introducción de datos y aceptan su salida de datos. De forma similar, las conexiones también se deben hacer para cualquier dispositivo añadido recientemente. Obsérvese que aún no se ha completado la capacidad de cambiar un dispositivo sin comprobar si se necesitan guardar o descartar los parámetros. Actualmente, APCATS 900 descarta cualquier cambio realizado desde la última vez que se guardó.

Los bloques del dispositivos 916 y 920 pueden funcionar en dos modos: (1) modo sin fallos, que es el funcionamiento ininterrumpido normal del dispositivo, y (2) modo de fallos. El modo de fallos permite la simulación de la interrupción del dispositivo, es decir, el bloqueo de la salida de datos del dispositivo con respecto al estado interrumpido, mientras que los demás subbloques continúan su funcionamiento normal. Al final del fallo, el dispositivo se vuelve a encender reinicializándose por sí mismo. Se pueden programar los fallos especificando qué dispositivo ha fallado, el tipo de fallo que experimentó y la duración del fallo. Para habilitar el modo de protección en caso de fallo/de fallos y permitir que se programen los fallos, el usuario marca una casilla de comprobación 956 a la izquierda de un botón de modo de fallos 958. Si se ha marcado una casilla de comprobación 960 para el botón del emulador de banco de pruebas (APSe) 962 en el bloque de controlador 918, la casilla de comprobación del modo de fallos 956 se marca y deshabilita automáticamente de modo que no se pueda modificar. Si la casilla de comprobación 960 para el botón del emulador de banco de pruebas 962, que es un APS emulado (simulado), no está marcada en el bloque de controlador 918, el usuario puede usar la casilla de comprobación del modo de fallos 956 para seleccionar el modo de protección en caso de fallo/de fallos. Si se habilita el modo de fallos, se crea una salida de datos adicional que indica el tipo de fallo. De forma predeterminada, un valor de 0 (cero) indica el funcionamiento normal del dispositivo.

Para programar los fallos, el usuario hace clic en el botón de modo de fallos 958 (si se ha habilitado el modo de fallos) en el bloque del dispositivo 916 o 920 respectivo. Se abrirá una respectiva ventana de menú de fallos del dispositivo 964 que en la FIG. 25 es una ventana de menú de fallos del sensor. Como la ventana de menú de fallos del activador es similar, solo se analiza la ventana de menú de fallos 964. Las ventanas de menú de fallos 964 contienen botones 966 para diferentes fallos predefinidos. Se hace clic en estos botones 966 para introducir los fallos en una programación de fallos 968. La programación enumera diversos parámetros para los modos de fallos seleccionados, algunos de los cuales son editables. Los parámetros son: “n.os” 970, “modo de fallos” 972, “n.os de pestañas” 974, “tiempo de inicio del fallo” 976, “tiempo de finalización del fallo” 978, y “asociación” 980. El parámetro “n.os” 970 es el número de serie de la entrada de fallo. El parámetro “modo de fallos” 972 es el nombre del fallo, y el parámetro “n.os de pestañas” 974 es el número de pestaña del dispositivo al que se asigna el fallo. El dispositivo debe existir para que el fallo surta efecto. El parámetro “tiempo de inicio del fallo” 976 es el tiempo de inicio en días, horas y minutos. Cualquier carácter no numérico se puede usar para separar los números. Si solo se introduce un único número, se supone que representa los minutos. Si se introducen dos números, se supone que representan horas y minutos. El parámetro “tiempo de finalización del fallo” 978 es el tiempo de finalización en días, horas y minutos. La interpretación de los números introducidos sigue el mismo patrón usado para el tiempo de inicio.

El parámetro “asociación” 980 se usa para capturar comentarios. El número y nombre del fallo se introducen cuando se hace clic en un botón de fallo. Estos campos no son editables. Si no se introduce ningún tiempo de inicio, nunca se inicia el fallo. Si el tiempo de inicio introducido procede con el tiempo de finalización, el fallo comienza en el tiempo de inicio y se interrumpe en el tiempo de finalización. Si el tiempo de inicio es mayor o igual que el tiempo de finalización, el fallo comienza en el tiempo de inicio y permanece hasta el final del tiempo de la simulación. La ventana de menú de fallos 964 también tiene botones de línea de solicitud 982 en la parte inferior, que son: “reordenar”, que reordena los fallos por orden de tiempo de inicio ascendente; “guardar”, que retiene cualquier valor cambiado; “cancelar”, que reestablece los últimos valores guardados; “ayuda”, que abre una ventana de ayuda; y “cerrar”, que guarda cualquier cambio y cierra la ventana. Los botones guardar y cancelar solo se habilitan si se ha alterado cualquier información en la programación desde que se guardó por última vez. Los elementos restantes mostrados en la ventana de menú de fallos 964 se explican por sí mismos.

Controlador

El bloque de controlador 918 es similar al bloque de planta 914. Enumera todos los controladores disponibles como selecciones de botones de radio, lo que permite seleccionar solo uno a la vez. Para seleccionar un modelo de controlador, hacer clic en el botón de radio 984 del modelo. Se ha de observar que el cuidado automático que estabilizará al paciente con respecto a las influencias variables de las excitaciones externas se controla y corrige por el módulo de controlador. Esto se realiza administrando correctamente los medicamentos de manera continua. Aunque el APCATS 900 proporciona un listado de algoritmos de control estándar que se han de probar, también tiene la opción de introducir un controlador definido por el usuario. La idea básica es proporcionar una situación de tipo enchufar y ejecutar el controlador. Las opciones pueden parecer como sigue: Controlador 1 (modificar parámetros); y controlador 2 (modificar parámetros)...; y controlador n (modificar parámetros). Después de seleccionar un modelo de controlador, aparecerá una ventana de parámetros del controlador. Como la ventana de parámetros del controlador es similar al menú de planta 922 (FIG. 24), la ventana de parámetros del controlador no se muestra y no se proporciona ningún otro análisis sobre cómo ajustar los parámetros del controlador enumeradas. Cada vez que se altera el controlador, se interrumpen las conexiones de introducción de datos y salida de datos existentes previamente. Antes de ejecutar una simulación, el usuario debe crear nuevas conexiones entre el controlador y los módulos que suministran su introducción de datos y aceptan su salida de datos.

Emulador de banco de pruebas

Marcando la casilla de comprobación 960 en el bloque de controlador 918 (FIG. 22) se habilita el botón pulsador del emulador de banco de pruebas 962, que cuando se hace clic en él aparece una ventana de emulador de banco de pruebas 986, como se muestra mediante la FIG. 26. La ventana de emulador de banco de pruebas 986 se usa para vincular las perturbaciones con los tipos de acontecimiento. La ventana de emulador de banco de pruebas 986 en la mitad superior contiene los botones de tipo de acontecimiento 990, agrupados en cuatro columnas. Los botones 990 en una columna dada se relacionan con el mismo aspecto específico de un acontecimiento y representan las funciones del acontecimiento que se pueden activar. Cada botón 990 se asocia con una perturbación definida a través del módulo de perturbaciones. Haciendo clic en uno de estos botones 990 se introduce el acontecimiento correspondiente, llamado acontecimiento desencadenado, en una programación de acontecimientos 992 localizado en la sección inferior de la ventana. La programación de acontecimientos 992 es el calendario de cuándo está programado que se produzcan los acontecimientos (perturbaciones), sus duraciones y magnitudes. Para asociar una perturbación con un acontecimiento en la programación, en primer lugar el usuario hace clic, a la izquierda, en la perturbación para seleccionarla. La fila aparecerá resaltada en amarillo. Luego, hacer clic en uno de los botones 990 asociados para que se introduzca el tipo de acontecimiento en esa fila. Entonces, el usuario procede a introducir los valores restantes en esa fila.

Cuando se desencadena, el acontecimiento desencadenado tan solo activa el modelo de paciente seleccionado comprobado en el bloque de planta 914 (FIG. 22). El bloque de controlador 918 reconoce una perturbación asociando con él un acontecimiento desencadenado apropiado. Un acontecimiento desencadenado enumerado en la columna “lista de acontecimientos” tiene varias propiedades: tiempo de activación, mostrado como “tiempo de inicio del acontecimiento”; “tipo de acontecimiento”; tiempo de activación relativo, mostrado como “tiempo de acción de ALGO”; duración del acontecimiento, mostrada como “tiempo de extensión de la acción”; y “cantidad”. El tipo de acontecimiento es un código de acontecimiento usado por el algoritmo. Se puede introducir haciendo clic en uno de los botones de tipo de acontecimiento o bien introduciendo el código correspondiente (dado entre paréntesis en el botón). El tiempo de activación relativo, con respecto al tiempo del acontecimiento que se produce físicamente en el que el bloque de controlador 918 (es decir, ALGO 500) reconoce el acontecimiento desencadenado. Se puede informar al bloque de controlador 918 de la ocurrencia: (a) antes de que ocurra el acontecimiento real (número negativo); (b) simultáneamente con la ocurrencia del acontecimiento; (c) cierto tiempo después del acontecimiento real (número positivo). La duración del acontecimiento se usa para seleccionar la duración en la que un acontecimiento permanece activo después de desencadenarse. La cantidad del acontecimiento se usa para seleccionar la magnitud del acontecimiento.

La parte inferior de la ventana de emulador de banco de pruebas 986 contiene botones de menú de solicitud 994. Los botones 994 y sus funciones son como sigue. “Ini del paciente” presenta la ruta y el nombre del archivo de inicialización PatientIni. El archivo PatientInin contiene los parámetros del paciente que usan por el controlador (por ejemplo, APS 500). “Directorio de experimentos” presenta la localización del directorio donde residirán los datos, y “guardar” guarda y actualiza los valores con respecto a los cambios actuales. “Cancelar” rechaza los cambios y carga de nuevo los últimos valores guardados, y “ayuda” presenta una pantalla de ayuda. “Cerrar” guarda cualquier valor actualizado y cierra la ventana. Si se desea, también se puede proporcionar un botón de actualización.

Perturbaciones externas

El bloque de perturbaciones externas 912 (FIG. 22) proporciona un medio para simular respuestas con respecto al consumo de carbohidratos, la actividad física y otras actividades esperadas de una persona que lleva una vida normal y saludable. Para que un paciente diabético pueda llevar una vida normal, sus funciones corporales se deben ajustar para hacer frente a dichas perturbaciones/excitaciones. La solidez, eficacia y estabilidad del sistema de bucle cerrado se evalúan investigando (1) los cambios de los valores de parámetro del modelo en el intervalo de funcionamiento y (2) todas las posibles situaciones de perturbaciones/excitaciones externas. Haciendo clic en el bloque de perturbaciones externas 912 en la ventana principal del APCATS 902, se presenta una ventana de menú de perturbaciones externas 996, tal como se muestra mediante la FIG. 27. Se proporciona un conjunto de botones de función de excitación 998 que están predefinidos con el título designado "SEl Ec C iONAR OPCIONES DE EJERCICIO DIETA ACUM.", como se muestra mediante la FIG. 27. Las funciones de excitación adicionales se introducen fácilmente en la lista escribiendo nuevas funciones como se describe en una sección posterior y modificando un archivo de inicialización DietInit. Las opciones están disponibles para someter a prueba diversas situaciones, un conjunto estándar de casos de prueba o un caso de un usuario arbitrario. Estos se crean usando las funciones de perturbación y programando sus ocurrencias.

Los botones 998 pueden estar habilitados o deshabilitados, ya que las perturbaciones disponibles para la selección dependen del modelo de paciente (planta) seleccionado. Por tanto, para un modelo de paciente dado, solo las perturbaciones definidas para ese modelo de paciente están habilitadas y disponibles para la selección. Las perturbaciones se pueden introducir en cualquier orden. La ventana de menú de perturbaciones externas 996 también proporcionó una programación de perturbaciones externas 1000 para configurar la duración de la simulación. La programación de perturbaciones externas 1000 enumera lo siguiente en forma de columna: número de la perturbación; nombre de la perturbación; intensidad en la escala; tiempo de inicio; tiempo de finalización; y asociación. El número y nombre de la perturbación no son editables, pero se fijan cuando se usan los botones de selección de perturbaciones para introducir las perturbaciones en la tabla. El valor de intensidad en la escala permite al usuario escalar el valor de salida en un factor. El valor de escala predeterminado de 1 indica una perturbación nominal. Como las columnas restantes de la programación 1000 son similares a la programación de la ventana de emulador de banco de pruebas 986 (FIG. 26) en su uso para programar que las perturbaciones (excitaciones) se produzcan durante el periodo de la simulación, no se proporciona, por tanto, otro análisis al respecto. Además, como los botones de menú de solicitud 1002 en la parte inferior de la ventana de menú de perturbaciones externas 996 también son similares a los botones proporcionados en el menú de fallos 952, tampoco se proporciona otro análisis.

Interconectar las salidas de datos de perturbación con parámetros de planta

Una excitación externa, en general, controla los parámetros de planta, así como la introducción de datos con respecto a la planta. En este caso particular, cada una de las funciones de perturbación se considera que es un módulo con salidas de datos que consisten en (1) las salidas de datos que se deben conectar al bloque de planta 914 y (2) los parámetros de perturbación que están en correspondencia uno a uno con los parámetros de planta. La(s) salida(s) de datos de perturbación más las salidas de datos de parámetros de la perturbación se envían para convertirse en la introducción de datos y los parámetros del modelo de planta. Sin embargo, existe una consideración importante cuando se producen múltiples perturbaciones simultáneamente. Los efectos de las múltiples funciones de perturbación se superponen sumando las salidas de datos de todas las perturbaciones para formar una única salida de datos vectorizada, que se convierte en la introducción de datos con respecto al bloque de planta 914. Para poder hacer esto se requiere que, entre los modelos de perturbación, cada una de las salidas de datos de perturbación se ajuste a las demás salidas de datos perturbación en el número de salidas de datos y su orden. Sin embargo, desde la perspectiva del bloque de perturbación 912, no existe ninguna restricción al número de datos de salida o su orden. Por otra parte, las salidas de datos de parámetros deben estar de acuerdo en orden, así como número, con la planta seleccionada. Cuando múltiples perturbaciones actúan simultáneamente, a diferencia de las salidas de datos descritas anteriormente, los parámetros no se añaden, sino que, más bien, el conjunto de parámetros de cada una de las perturbaciones se resuelve y se determina un único conjunto de valores de parámetro. La función que controla esta situación es una función de filtro.

Después de introducir una perturbación externa en la ventana de menú de perturbaciones externas 996, la función de filtro obtiene el número de parámetros del modelo de paciente seleccionado. Los estados de funcionamiento de todas las dietas (funcionamiento= 1; sin funcionamiento = 0) se multiplexan con los valores de parámetro que proceden de las dietas. El número de dietas se computa usando la siguiente lógica: Número de dietas = longitud del vector de introducción de datos/(1 longitud de los parámetros). Los tiempos de inicio y finalización introducidos de la perturbación externa se convierten en los tiempos en los que la función se activa y en los que se detiene. La función matemática que describe la dieta es independiente del tiempo de inicio. Con respecto al tiempo de finalización, la función puede tener un curso de tiempo fijo y, en dicha situación, existen un par de formas de tratar el tiempo de finalización. La función, en general, es una ecuación diferencial, estando todas sus condiciones y parámetros iniciales descritos en la función. El comportamiento de la función es la respuesta normalizada. La salida de datos se escala por el valor de escala introducido proporcionado en la programación de acontecimientos 1000 en la columna "intensidad en la escala". Aunque se espera normalmente un valor de escala positivo, se puede introducir un valor negativo para simular un efecto negativo.

Formulario para los puertos de conexión

Haciendo clic en una línea de conexión mostrada en la ventana principal del APCATS 902 aparece un formulario para los puertos de conexión 1004 que se muestra mediante la FIG. 28. En su lado izquierdo, el formulario para los puertos de conexión 1004 enumera y numera las salidas de datos 1006 disponibles. Las salidas de datos 1006 se generan por el bloque que envía la información. El lado derecho presenta las introducciones de datos 1008 del bloque que recibe la información, junto con cuadros de edición vacíos. Para crear una conexión entre una salida de datos 1006 específica y una introducción de datos 1008 específica, el usuario escribe el número correspondiente con respecto a la salida de datos en el cuadro de edición adyacente al campo de introducción de datos que ha de recibir en la salida. Cualquier introducción de datos 1008 que no esté conectada a una salida de datos 1006, es decir, tenga un cuadro de edición en blanco, se fija en cero. También obsérvese que una introducción de datos 1008 no se puede conectar a más de una salida de datos 1006. No es necesario que todas las salidas de datos estén conectadas a una introducción de datos. La simulación generará datos para todas las salidas enumeradas, pero las que se dejen sin conectar simplemente no se han de usar como introducción de datos con respecto al próximo módulo. Las salidas de datos se pueden conectar a más de una introducción de datos. Al completar todas las conexiones deseadas, hacer clic en el botón “X” (cerrar ventana) en la esquina superior derecha para guardar las conexiones y cerrar el formulario.

Panel ejecutar/almacenar

El panel ejecutar/almacenar 904 de la ventana principal del APCATS 902, que está ampliado mediante la FIG. 29, proporciona la funcionalidad básica para cargar datos, guardar datos y ejecutar simulaciones. Además, presenta configuraciones experimentales, permite al usuario introducir un resumen experimental y, por último, permite al usuario salir del APCATS 900. La columna más a la izquierda del panel ejecutar/almacenar 904 presenta entradas realizadas y modificadas en un formulario para la entrada de inicio 1010 (FIG. 32). Los tres elementos de información que presenta, de arriba a abajo, son: nombre de usuario; el grupo del experimento y el número de identificación del experimento; y el paradigma en uso (intravenoso-intravenoso, subcutáneo-subcutáneo, intravenoso-subcutáneo). Para introducir detalles y comentarios sobre el experimento, hacer clic en el botón introducir el resumen del experimento 1012. Haciéndolo aparecerá la ventana “APCATS 900 - añadir particularidades sobre el experimento actual” (no mostrado). La información introducida en esta ventana se almacena en el archivo de documentación (doc) del experimento. Esta información se puede actualizar cualquier número de veces.

Para compilar las configuraciones de APCATS 900 actuales y guardarlas, los usuarios hacen clic en el botón ver estado 1014. Al hacerlo, la información de estado se escribe en una localización temporal (área de trabajo) y se presenta en un editor. Para guardar las configuraciones actuales de las variables de introducción de datos en un archivo, el usuario hace clic en el botón guardar serie de documentos acum. 1016. La documentación de configuración presentada cuando se hace clic en el botón ver estado 1014 también se guarda. Las configuraciones de inicialización actuales necesarias para recrear el experimento se escribe en un archivo temporal en el área de trabajo. Si APCATS 900 falla, entonces, las configuraciones guardadas en este archivo se pueden reestablecer haciendo clic en el botón antiguo 1015 en el formulario para la entrada de inicio (FIG. 32), y buscando el archivo temporal en el directorio del archivo enumerado. Para que aparezca el formulario para la entrada de inicio 1010 en cualquier momento, hacer clic en el botón del FORMULARIO PARA LA ENTRADA DE INICIO 1018. El formulario para la entrada de inicio 1010 (FIG. 32) se usa para editar los detalles necesarios para definir el alcance del experimento y mantener los registros adecuados. Para salir de APCATS 900, hacer clic en el botón “SALIR DE APCATS” 120. Aparece el cuadro de diálogo "salir del APCATS" (no mostrado) que permite al usuario regresar al APCATS 900 y cancelar la solicitud de salida. Haciendo clic en el botón continuar se procederá con el cierra de la aplicación. Cerrará todas las ventanas generadas por APCATS antes de cerrar la ventana de APCATS 900 principal.

Para iniciar una simulación, el usuario hace clic en el botón iniciar simulación 1022. Al hacerlo, aparecerá la ventana de parámetros de simulación 1024 mostrada mediante la FIG. 30. La ventana de parámetros de simulación 1024 permite al usuario fijar los tiempos de inicio y detención de una simulación, seleccionar una rutina de integración y un tamaño de etapa, y ejecutar la simulación. La mayoría de los campos son autoexplicativos. De forma predeterminada, las ejecuciones de simulación se inician en el tiempo 0. La introducción de un valor distinto de cero proporciona una desviación del tiempo de inicio. Para fijar el tiempo de finalización de las ejecuciones de la simulación, el usuario introduce un valor en un cuadro de texto tiempo de detención. El tiempo de detención debe ser mayor que el tiempo de inicio para que se ejecute una simulación. Para configurar la rutina de integración que se ha de usar en la simulación, el usuario la selecciona de un menú desplegable solucionador 1026. Para fijar el tamaño de etapa de integración, el usuario lo selecciona de un menú desplegable de tamaños de etapa 1028. Para el periodo de tiempo para guardar datos, el usuario introduce el periodo entre los datos guardados. La tolerancia relativa es un criterio de convergencia de integración. La tolerancia absoluta también es un criterio de convergencia de integración. El usuario selecciona un valor de un cuadro desplegable 1030 para fijar la ventana de tiempo que se presentará durante la simulación. Las selecciones disponibles son cada hora, un cuarto del día, medio día o diariamente, y toda la simulación. Para el nombre del archivo del modelo Simulink, una marca definida en el archivo init controla si un usuario puede o no renombrar un archivo del modelo de simulación. Si está autorizado, el usuario puede introducir el nombre de un archivo de Simulink en el cuadro de edición del nombre del modelo Simulink. Para solo generar modelo, una marca definida en el archivo init controla si un usuario puede o no generar y ver un modelo. Si está autorizado, el usuario puede hacer clic en el botón generar modelo 1032 para generar el modelo Simulink para el que se introdujo un nombre de archivo en el cuadro de texto nombre del modelo Simulink. Entonces, el usuario puede echarle un vistazo al modelo abriendo un archivo del modelo (mdl).

Ejecución de simulación

Para comenzar la simulación, el usuario hace clic en un botón de inicio 1034. Haciendo clic en este botón, se activarán las siguientes acciones: se crean y guardan archivos de documentación e inicialización; se fija el bucle de estudio paramétrico; se crea y simula un diagrama de bloques de Simulink, y se guardan los datos resultantes. Para experimentos sistemáticos (S) o exploratorios (E), se genera un número de identificación del experimento y los archivos de datos nombrados apropiadamente se guardan en un directorio del sistema. Si existe un problema para guardar los archivos aquí, en su lugar, se mueven a un directorio de datos estacionado, localizado normalmente en el disco duro local del usuario. Para los experimentos en el grupo (P) en juego, se le pide al usuario que proporcione un número de identificación del experimento. Para los experimentos sistemáticos (S) o exploratorios (E), la información de registro se añade a los archivos log mantenidos en una unidad de red. Haciendo clic en un botón continuar 1036 se continuará una simulación desde un estado ya terminado, extendiendo la simulación. Haciendo clic en un botón de pausa/reanudación 1038 se pausará una simulación en ejecución o se reanudará una simulación en pausa. Para detener la simulación en progreso, el usuario hace clic en un botón de detención 1040. Si una simulación se detiene por el usuario, no se guardará ningún dato de la simulación parcial. Esto previene la creación de conjuntos de datos incompletos. El reloj de simulación presenta la hora del reloj de simulación. Esto permite al usuario monitorizar el progreso de una simulación. Los n.os de ejecuciones actuales/totales muestran, en notación hexadecimal, el número de ejecuciones actuales y las ejecuciones totales del experimento.

Después de una ejecución de simulación, APCATS 900 generará datos de salida. Las siguientes opciones están disponibles para el usuario: generar medidas del rendimiento; decidir, antes de la simulación, qué salidas de datos se han de generar y guardar; generar todas las posibles salidas de datos y, entonces, decidir qué salidas de datos se han de guardar; generar y guardar todas las salidas de datos; visualizar las salidas de datos; y guardar las salidas de datos con respecto a los archivos en formato de ASCII binario o cualquier otro número de formatos electrónicos adecuados. Guardar los datos en forma binaria tiene la ventaja de ser conciso, pero el transporte de los datos se vuelve limitado. Mantener los archivos de datos de ASCII, por otra parte, los dispone en forma legible y también los hace fácilmente transportables a otro programa informático para otro análisis de los datos.

El panel de gráficas

El panel de gráficas 908 de la ventana principal del APCATS 902 permite al usuario mostrar en gráficos los datos experimentales en una pantalla o como una copia en papel, y está ampliado mediante la FIG. 31. Un control del número de ejecuciones 1042 tiene dos propósitos: (a) durante la simulación presenta el número de la ejecución experimental que se está simulando actualmente, y (b) fuera de la simulación se usa para seleccionar el/los número(s) de ejecución para los que los datos se mostrarán en gráficas. El número de ejecuciones se presenta en forma hexadecimal. Para seleccionar múltiples ejecuciones contiguas cuando se seleccionan los datos que se han de mostrar en gráficas, el usuario mantiene presionada la tecla mayúsculas mientras que usa el botón izquierdo del ratón para seleccionar los primeros y últimos números del intervalo de ejecuciones que se han de mostrar en gráficas. Para seleccionar múltiples ejecuciones discretas, mantener presionada la tecla control mientras que usa el botón izquierdo del ratón para hacer clic en los números individuales de las ejecuciones que se han de mostrar en gráficas. Los controles mín. y máx. 1044 y 1046, respectivamente, presentan los números de ejecuciones mínimos y máximos en forma hexadecimal. Un control deslizante 1048 proporciona un procedimiento alternativo de selección del número de ejecuciones que se han de mostrar en gráficas. Los extremos izquierdo y derecho del control deslizante representan respectivamente los números de ejecuciones mínimos y máximos.

El plano de gráfica 908 se puede dividir en subgráficas más pequeñas alineadas en filas y columnas. Para seleccionar el número de filas o el número de columnas, el usuario introduce los valores deseados en los cuadros de texto n.os de filas y n.os de columnas. Por ejemplo, introduciendo 2 como el número de filas y 3 como el número de columnas se crearán seis subgráficas, tres en cada dos filas. Una vez que se haya establecido el número de subgráficas, el usuario selecciona la información que se ha de presentar en cada subgráfica. Para configurar una subgráfica dada, el usuario selecciona la subgráfica de un cuadro desplegable de subgráficas de selección 1050. Las subgráficas se enumeran usando notación matricial, representando el primer número entre paréntesis la fila de la subgráfica y representando el segundo número la columna. Para cada subgráfica, introducir la información necesaria en los controles debajo del cuadro desplegable de subgráficas de selección.

Para fijar la etiqueta para el eje x, el usuario introduce la etiqueta en el cuadro de texto etiquetar eje X. Si el cuadro de texto se deja vacío, el nombre de la variable independiente (x) seleccionada se usará como etiqueta. El usuario selecciona la variable independiente frente a la que los datos se han de mostrar en gráficas desde un menú desplegable 1052 localizado debajo del control etiquetar eje X. Se pueden seleccionar diferentes variables independientes para cada una de las subgráficas. La selección predeterminada es el tiempo.

Para fijar la etiqueta para el eje y, el usuario introduce la etiqueta en un cuadro de texto etiquetar eje Y. Si el cuadro de texto se deja vacío y solo se selecciona una variable independiente (y), el nombre de la variable seleccionada se usará como etiqueta. Si el cuadro de texto se deja vacío y se selecciona más de una variable independiente, la etiqueta del eje y será “* * *”. El usuario selecciona las variables dependientes para mostrarlas en gráficas de un cuadro de lista 1054 localizado justo por encima del botón mostrarlo en gráficas. Para seleccionar múltiples variables contiguas, el usuario mantiene presionada la tecla mayúsculas mientras que usa el botón izquierdo del ratón para seleccionar las primeras y últimas variables en el intervalo. Para seleccionar múltiples variables discretas, el usuario mantiene presionada la tecla control mientras que usa el botón izquierdo del ratón para hacer clic en las variables individuales. Se pueden seleccionar hasta cinco variables dependientes para cada subgráfica. Las variables seleccionadas se enumerarán en el cuadro de texto sobre la lista de selección.

Una vez que se hayan introducido los parámetros para cada una de las subgráficas, se pueden presentar e imprimir las gráficas. No se pueden crear gráficas hasta que una simulación se haya terminado de ejecutar. Sin embargo, es posible mostrar en gráficas los datos de la simulación previa. Para presentar las gráficas en la pantalla, el usuario hace clic en el botón mostrarlo en gráficas 1056. Aparecerá la ventana de gráfica, presentando los gráficos. Para crear una copia impresa (en papel) de las gráficas, el usuario hace clic en un botón imprimir 1058. Aparece un cuadro de diálogo (no mostrado), que permite al usuario seleccionar diversas opciones de impresión.

Modificar archivos de inicialización

Cuando se inicializa APCATS 900, todos los modelos disponibles se cargan con sus valores predeterminados. Las alteraciones posteriores a los valores se mantendrán por estos objetos. Los valores predeterminados se mantienen en los diversos objetos gráficos de la ventana principal del APCATS 902. Cada objeto gráfico tiene diversas propiedades, siendo las dos más importantes para cada uno datos del usuario y valor. Las subsecciones posteriores detallan la información gestionada por las propiedades para cada uno de los bloques. Las siguientes subsecciones presentan el contenido de los diversos archivos de inicialización antes de cualquier modificación por el usuario. ModelInit.m

DietInit.m

SensorInit.m

ActuatorInit.m

ControlInit.m

SenFailInit.m

ActFailInit.m

Definir modelos de perturbación

Lo siguiente es un código parcial para las perturbaciones externas que se puede usar como una plantilla para crear perturbaciones adicionales.

Definir modelos de paciente

Lo siguiente es un ejemplo del código para un modelo de planta que también se puede usar como plantilla para desarrollar modelos de paciente adicionales.

Definir modelos de dispositivo

Lo siguiente proporciona un código parcial para dispositivos que también se puede usar para desarrollar modelos de dispositivo adicionales.

Definir modelos de control

Lo siguiente proporciona un código parcial para los modelos de controlador que se puede usar como una plantilla para desarrollar crear modelos de controlador adicionales.

Archivo de simulación (mdl)

El siguiente ejemplo muestra un archivo de simulación (mdl) que, como se menciona anteriormente, se puede modificar según lo desee el usuario.

La descripción anterior de la invención se ha presentado para propósitos de ilustración y descripción. No pretende ser exhaustivo o limitar la invención a la forma precisa divulgada, y otras modificaciones y variaciones pueden ser posibles en vista de las enseñanzas anteriores. Los modos de realización anteriores divulgados se eligieron y describieron para explicar los principios de la invención y su aplicación práctica para posibilitar, de este modo, que otros expertos en la técnica utilicen de la mejor manera la invención. Se pretende que las reivindicaciones adjuntas se interpreten para que incluyan otros modos de realización alternativos de la invención, excepto en la medida en que esté limitada por la técnica anterior.

Claims (13)

REIVINDICACIONES

1. Un procedimiento computerizado para ayudar a garantizar que la selección de una opción sea pertinente para lograr un objetivo del tratamiento de un paciente con diabetes, comprendiendo el procedimiento:

especificar por medio de un dispositivo de introducción de datos (36, 40) de un ordenador (14) uno o más protocolos de obtención de datos contenidos en un módulo de protocolos de obtención de datos (70) que abordan necesidades de diagnóstico y tratamiento específicas del paciente con diabetes;

seleccionar por medio del dispositivo de introducción de datos (36, 40) del ordenador (14) un modelo de paciente disponible en un módulo de modelos de paciente (72) que modela matemáticamente uno o más aspectos de la fisiología humana definidos en ecuaciones diferenciales;

realizar un análisis sobre el modelo de paciente seleccionado por medio de la ejecución de submódulos del módulo de modelos de paciente en el ordenador (14) que determina parámetros del modelo de paciente seleccionado empleando técnicas de ajuste de datos;

realizar una verificación del modelo de los parámetros determinados por medio de un módulo de validación del modelo (74) que se ejecuta en el ordenador, lo que garantiza que el modelo de paciente seleccionado haya capturado la dinámica apropiada que aborda las necesidades de diagnóstico y tratamiento específicas del paciente; y caracterizado por,

introducir en el ordenador (14) datos específicos del paciente obtenidos por un dispositivo externo (48) según el uno o más protocolos de obtención de datos especificados en los que el ordenador (14) comprueba la calidad de los datos específicos del paciente obtenidos con un procedimiento de calidad de los datos en forma de un módulo matemático que examina la calidad de los datos obtenidos en términos de su rendimiento y/o propiedades estadísticas y proporciona en un monitor (36) del ordenador (14) una serie de recomendaciones del tratamiento para el paciente, cada una con una clasificación de pertinencia que se basa en la selección del efecto de dicha recomendación del tratamiento en base a la calidad de los datos específicos del paciente obtenidos que tendrá en la generación de cambios en el tratamiento del paciente,

aplicar los datos específicos del paciente al modelo de paciente seleccionado para generar parámetros del tratamiento a partir del modelo después de la selección de una de las recomendaciones del tratamiento, y

realizar un análisis realizando simulaciones in silico para cuestionar los casos críticos en cuanto a la solidez del tratamiento y evaluar la estabilidad de la solución por medio de un módulo de análisis (76) que se ejecuta en el ordenador (14) usando los datos específicos del paciente aplicados y el modelo de paciente seleccionado que proporciona en el monitor (36) del ordenador (14) al menos un tratamiento específico del paciente recomendado en base a parámetros del tratamiento que comprenden la tasa basal, la sensibilidad a la insulina y la proporción de carbohidratos con respecto a insulina generados a partir del modelo seleccionado para su aprobación.

2. El procedimiento computarizado de acuerdo con la reivindicación 1 comprende además ajustar el tratamiento específico del paciente recomendado.

3. El procedimiento computarizado de acuerdo con la reivindicación 1 comprende además definir e implementar situaciones de prueba en el ordenador que ayudan a someter a prueba el tratamiento específico del paciente recomendado y cuantificar la calidad del tratamiento que se puede lograr potencialmente usando el tratamiento específico del paciente recomendado.

4. El procedimiento computarizado de acuerdo con la reivindicación 1 comprende además definir e implementar situaciones de prueba en el ordenador que ayudan a realizar la verificación del modelo de los parámetros.

5. El procedimiento computarizado de acuerdo con la reivindicación 1 comprende además confirmar la dinámica del modelo de paciente simulando casos de prueba especiales para evaluar la respuesta dinámica frente a al menos uno de los datos de la literatura y datos clínicos.

6. El procedimiento computarizado de acuerdo con la reivindicación 1 comprende además proporcionar un entorno simulado para definir e implementar situaciones de prueba en el ordenador que ayudan a realizar la verificación del modelo de los parámetros.

7. El procedimiento computarizado de acuerdo con la reivindicación 1 comprende además implementar el tratamiento específico del paciente recomendado en una unidad portátil.

8. El procedimiento computarizado de acuerdo con la reivindicación 1 comprende además obtener los datos según el uno o más protocolos a partir de un dispositivo de obtención de datos del paciente.

9. El procedimiento computerizado de acuerdo con la reivindicación 1 comprende además usar un algoritmo en el ordenador para dirigir la obtención de datos, la realización de análisis sobre los datos, la aplicación de los datos al modelo de paciente y la proporción del tratamiento específico del paciente recomendado.

10. El procedimiento computarizado de acuerdo con la reivindicación 1, en el que los datos obtenidos incluyen al menos una de actividades de acontecimiento y mediciones fisiológicas que actualizan el análisis para proporcionar el tratamiento específico del paciente recomendado.

11. El procedimiento computarizado de acuerdo con la reivindicación 1 comprende además aprobar el tratamiento específico del paciente recomendado como una receta, y usar un algoritmo en el ordenador para dirigir la planificación, control y monitorización de la receta.

12. El procedimiento computarizado de la reivindicación 1, en el que el tratamiento incluye si una acción particular tendrá un efecto que sea adverso o deseado.

13. Un sistema computarizado para ayudar a garantizar que la selección de una opción sea pertinente para lograr un objetivo del tratamiento de un paciente con diabetes, comprendiendo el sistema:

un ordenador (14) que tiene:

un módulo de modelos de paciente (72) que tiene una pluralidad de modelos de paciente que modela matemáticamente uno o más aspectos de la fisiología humana definidos en ecuaciones diferenciales y que realizará un análisis sobre un modelo de paciente seleccionado para determinar parámetros del modelo de paciente seleccionado empleando técnicas de ajuste de datos;

un módulo de validación del modelo (74) que garantiza que el modelo de paciente seleccionado aborda las necesidades de diagnóstico y tratamiento específicas del paciente con diabetes; y caracterizado por,

un módulo de protocolos de obtención de datos (70) que contiene uno o más protocolos de obtención de datos que aborda necesidades de diagnóstico y tratamiento específicas del paciente y que comprueba la calidad de datos específicos del paciente obtenidos con un procedimiento de calidad de los datos en forma de un módulo matemático que examina la calidad de los datos obtenidos en términos de su rendimiento y/o propiedades estadísticas y proporciona en un monitor (36) del ordenador (14) una serie de recomendaciones del tratamiento para el paciente, cada una con una clasificación de pertinencia que se basa en la selección del efecto de dicha recomendación del tratamiento en base a la calidad de los datos específicos del paciente obtenidos que tendrá en la generación de cambios en el tratamiento del paciente, y

un módulo de análisis (76) para realizar simulaciones in silico para cuestionar los casos críticos en cuanto a la solidez del tratamiento y evaluar la estabilidad de la solución que usa los datos específicos del paciente aplicados para generar parámetros del tratamiento a partir del modelo y el modelo de paciente seleccionado para proporcionar en el monitor (36) al menos un tratamiento específico del paciente recomendado en base a parámetros del tratamiento que comprenden la tasa basal, la sensibilidad a la insulina y la proporción de carbohidratos con respecto a insulina generados a partir del modelo seleccionado para su aprobación.