ES2845400T3 - Sistema para determinar una administración de insulina y comunicar una dosis en un programa informático de páncreas automatizado - Google Patents

Sistema para determinar una administración de insulina y comunicar una dosis en un programa informático de páncreas automatizado Download PDF

Info

Publication number
ES2845400T3
ES2845400T3 ES12002462T ES12002462T ES2845400T3 ES 2845400 T3 ES2845400 T3 ES 2845400T3 ES 12002462 T ES12002462 T ES 12002462T ES 12002462 T ES12002462 T ES 12002462T ES 2845400 T3 ES2845400 T3 ES 2845400T3
Authority
ES
Spain
Prior art keywords
module
glucose
insulin
algo
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES12002462T
Other languages
English (en)
Inventor
Siva Chittajallu
Paul J Galley
Ajay Thukral
Stefan Weinert
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
F Hoffmann La Roche AG
Original Assignee
F Hoffmann La Roche AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by F Hoffmann La Roche AG filed Critical F Hoffmann La Roche AG
Application granted granted Critical
Publication of ES2845400T3 publication Critical patent/ES2845400T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G16H20/17—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered via infusion or injection
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
    • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
    • A61M5/168—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body
    • A61M5/172—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body electrical or electronic
    • A61M5/1723—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body electrical or electronic using feedback of body parameters, e.g. blood-sugar, pressure
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/20—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for electronic clinical trials or questionnaires
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/40—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for data related to laboratory analysis, e.g. patient specimen analysis
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/60—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to nutrition control, e.g. diets
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/50—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for simulation or modelling of medical disorders
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/70—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00—ICT specially adapted for the handling or processing of medical references
    • G16H70/20—ICT specially adapted for the handling or processing of medical references relating to practices or guidelines
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
    • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
    • A61M5/142—Pressure infusion, e.g. using pumps
    • A61M2005/14288—Infusion or injection simulation
    • A61M2005/14296—Pharmacokinetic models

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Public Health (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Biomedical Technology (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Pathology (AREA)
  • Medicinal Chemistry (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Chemical & Material Sciences (AREA)
  • Diabetes (AREA)
  • Veterinary Medicine (AREA)
  • Anesthesiology (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Hematology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Animal Behavior & Ethology (AREA)
  • Vascular Medicine (AREA)
  • Nutrition Science (AREA)
  • Bioethics (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Measurement Of The Respiration, Hearing Ability, Form, And Blood Characteristics Of Living Organisms (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Un sistema (10) para determinar una administración de insulina y comunicar una dosis en el programa informático de páncreas automatizado APS (502), comprendiendo el sistema un procesador (16, 34) que está configurado para ejecutar un controlador de algoritmo, ALGO, (510) y un módulo de algoritmo empírico, EA, (518) proporcionado en el controlador ALGO (510), en el que - el controlador de algoritmo ALGO (510) pasa entradas de información, incluyendo la información de glucosa más reciente, la información de administración de insulina anterior y la información de acontecimientos que comprende al menos uno de comidas, ejercicio e intervención de un paciente, al módulo EA (518) para determinar una recomendación de tratamiento, y - el módulo EA (518) proporciona la recomendación de tratamiento en base a las entradas de información, caracterizado por que a) el módulo EA (518) está estructurado como un grupo de módulos (800, 801, 802, 804, 806, 808, 810, 812, 814, 816, 818, 820, 822, 824, 826, 828, 830, 832, 834), manejando cada módulo un aspecto de la recomendación de tratamiento; b) el módulo EA (518) comprende un compensador digital con un horario basado en índices independiente del tiempo real, que determina la cantidad de control apropiada en base - al horario que existe en los índices de matrices de variables, y - a una selección de un período de ciclo de control Tc para cada ciclo de control del controlador ALGO, en el que cada período de ciclo de control Tc tiene un par de límites de control en un tiempo de inicio ts y un tiempo de finalización te, respectivamente; c) el controlador ALGO (510) comprende una descripción de horario que depende de una hora relativa t de ciclos de control transcurridos desde el inicio de un tratamiento TA0 implementado, en el que a cualquier hora relativa t dada, el controlador ALGO (510) determina a qué período de ciclo de control Tc pertenece una llamada actual al controlador ALGO (510) para una hora actual T, en el que la llamada al controlador ALGO (510) no está exactamente en el límite de control del tiempo de inicio ts del período del ciclo de control Tc, sino que, más bien, dentro de una precisión temporal dada sobre el límite de control del tiempo de inicio ts; y d) el controlador ALGO (510) funciona en un modo de bucle cerrado (600), en el que el controlador ALGO (510) se dispone por sí mismo en un modo de bucle abierto (700) desde el modo de bucle cerrado (600) cuando existe tanto la no disponibilidad de una medición de glucosa debida al retardo de medición determinado por un módulo de actualización de glucosa (808) del módulo EA (518) como una medición de glucemia desactualizada, que se indica por un módulo de glucosa desactualizado (814) del módulo EA (518), si el último valor de medición de glucemia recibido es más antiguo que un determinada franja de tiempo especificada.

Description

DESCRIPCIÓN
Sistema para determinar una administración de insulina y comunicar una dosis en un programa informático de páncreas automatizado
La presente invención se refiere en general a la gestión de enfermedades crónicas y, en particular, a un sistema informático para desarrollar tratamientos específicos de pacientes para la gestión de enfermedades crónicas en base al modelado dinámico de la fisiología del paciente y el procedimiento del mismo.
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 comenzando 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 gestiona 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 glucemia 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 carbohidratos, 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. El documento WO2005/113036A1 divulga un procedimiento y aparato para el control de la glucosa y la dosificación de insulina para diabéticos, que comprende un algoritmo de control lote a lote para supervisar los niveles de glucemia y ajustar la administración de insulina a medida que varían las condiciones. 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 variados 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 afecciones crónicas.
Para resolver el problema, se proporciona un sistema para determinar una administración de insulina y comunicar una dosis en un programa informático de páncreas automatizado APS de acuerdo con la reivindicación 1.
Estos y otros rasgos característicos y ventajas de la invención se entenderán más completamente a partir de la siguiente descripción de diversos modos de realización de la invención tomados conjuntamente con los dibujos adjuntos.
La siguiente descripción detallada de los modos de realizació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 de gestión 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 de 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;
la FIG. 3 es un diagrama de bloques de un modo de realización de programa informático usado en el sistema de la FIG. 2 y que muestra una parte 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;
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 de páncreas automático (APS) para desarrollar tratamientos específicos del paciente;
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;
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; las FIGS. 8 y 9 son diagramas de flujo del procedimiento que muestran una secuencia de ejecuciones de módulos de acuerdo con un algoritmo empírico;
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;
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 glucémica 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;
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 horario usadas por un algoritmo;
la FIG. 21 es un gráfico proporcionado como un ejemplo para ilustrar la identificación de parámetros del modelo; la FIG. 22 es una representación de una interfaz gráfica de usuario para un programa informático de paquete de prueba de algoritmo de control de páncreas automatizado (APCATS) 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;
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 de modelo de paciente para un entorno de simulació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;
la FIG. 26 es una representación de una interfaz gráfica de usuario que proporciona un formulario de entrada de acontecimientos para un entorno de simulació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;
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;
la FIG. 29 es una representación de una parte 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, 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 etapa, y ejecutar la simulación;
la FIG. 31 es una representación de una parte del panel de gráficas de la interfaz gráfica de usuario de la FIG. 22 que permite a un usuario hacer gráficos con 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;
la FIG. 33 es un flujo de procedimiento que muestra una secuencia de ejecución de componentes de programa informático;
la FIG. 34 es un gráfico que muestra un período de control; y
la FIG. 35 representa una actualización de variables con respecto a la llamada del algoritmo.
En un modo de realización, se 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 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.
Se usan 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.
La presente divulgació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 tratamientos existentes.
En otro ejemplo, se divulga un procedimiento que usa los datos de 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 ejemplo, posibilita además a un usuario realizar 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 requisitos tales como las directrices de la ADA y/o mantiene los parámetros clave, por ejemplo, HbA1C, dentro de un intervalo objetivo deseado del sujeto.
Se posibilita a un médico en ejercicio 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, examinar los resultados del tratamiento y entender las características del paciente. Se proporciona 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 particular, ahora se proporciona un análisis sobre las mediciones, análisis y otra informació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 glucemia por diversos motivos causales. Para gestionar la enfermedad, existen muchas introducciones de datos, herramientas de utilidad y dispositivos para la gestión 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 gestión de enfermedades típicos para gestionar la diabetes que necesitan interactuar e intercambiar información para determinar y evaluar la eficacia del tratamiento con insulina recetado. Los componentes de gestión de enfermedades incluyen: ordenadores personales, bases de datos centralizadas para la gestión de datos, algoritmos que proporcionan procedimientos para gestionar 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 glucemia (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 gestión 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 requisito 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 gestión 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 gestión de enfermedades. Los problemas adicionales radican en el hecho de que el intercambio de información cuando se gestiona una enfermedad crónica, tal como la diabetes, es crítico en el tiempo, así como crítico en 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 la gestión 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 aparición en el tiempo especificado o serie de apariciones 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?
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, 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 cuidado de la diabetes, las mediciones de glucosa obtenidas normalmente usando medidores de glucosa son los parámetros principales para llevar a cabo la gestión del tratamiento. Existen varios parámetros secundarios pertinentes para gestionar 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 la cantidad y las tasas de ejecución para el consumo de comida y el ejercicio) que es importante para ajustar y corregir el tratamiento. Se emplean dichos datos en mediciones y análisis para construir 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 modo que el usuario pueda entender el comportamiento dinámico subyacente de la enfermedad crónica. Dicho análisis y visualización ofrece un mayor entendimiento sobre el funcionamiento del sistema (la persona diabética) y puede ayudar al personal sanitario con el diagnóstico, determinación del tratamiento y pronóstico. En consecuencia, se 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, 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, a continuación, 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 construir modelos y representar la farmacocinética y farmacodinámica subyacentes. En general, los datos mencionados anteriormente se obtienen usando protocolos bien definidos. El procedimiento engloba los siguientes aspectos. Se obtienen datos específicos del paciente para respaldar las herramientas de diagnóstico, tratamiento y pronóstico. Se propone un análisis de los datos reconociendo que los 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 reconociendo que los estudios basados en la población representan efectos promedio y no abordan necesariamente las necesidades específicas del paciente. 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 que pueden tener una influencia sustancial sobre el efecto de los medicamentos. Una herramienta sistemática 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.
Sistema global
Con las mediciones y análisis anteriores en mente, el DTPS es un sistema de 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 supervisión de la tensión arterial, un dispositivo de supervisió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 de otros fármacos para reducir o aumentar la glucemia, un dispositivo de mano u otro dispositivo de obtención de datos para supervisar los datos sobre la ingesta de comidas del paciente, datos sobre el ejercicio del paciente, datos sobre la afección 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 comunicar 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 parte 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.
Partes 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. 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 parte de protocolo de red 52, una parte de aplicaciones básicas 54 y una parte de módulos funcionales 56. El sistema operativo y la parte 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 partes de aplicaciones básicas 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 parte de aplicaciones básicas 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 parte de aplicaciones básicas 54 puede contener paquetes de programa informático matemáticos convencionales. En general, dichas herramientas matemáticas básicas 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 se limitan 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 parte de aplicaciones básicas 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 y 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 parte de aplicaciones básicas 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 parte de aplicaciones básicas 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 parte 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 conjuntos de reglas/directrices 78. La parte de módulos funcionales 56 incluye además un módulo de gestión de controladores del dispositivo y un módulo de validación y presentación de los resultados 82. De forma ilustrativa, la parte 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 parte de aplicaciones básicas 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 parte 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 afección en general, y para una afección 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 afección particular para la que se desarrolla el tratamiento, la gravedad de la afección, 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 objetivo 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 requisitos definidos para los datos particulares que se han obtenido. Los ejemplos de dichos requisitos incluyen, pero no se limitan 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 los 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 se limitan 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 afección, 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 introducción de datos 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 se limitan 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 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 como una 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, afección 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 como una 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 una correlación con 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 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 la correlación de modelos y/o parámetros del modelo con 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, a continuación, 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 que 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 uno o más terceros.
Cuando se ha seleccionado un modelo particular usando el módulo de modelos de paciente 72, a continuación, 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 hipótesis 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 un procedimiento o marco de identificación de parámetros del modelo de este tipo, que de ninguna forma se debe considerar limitante, es uno que: i) proporciona los parámetros del modelo y las hipótesis iniciales para los parámetros, ii) si se sigue un enfoque bayesiano, proporciona una distribución a priori 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, un modo de realizació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, 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 cuidado 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 gestionar 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 se limitan 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 supervisar 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 se limitan 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 afección, 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 supervisar, dinámica o estáticamente, la fisiología subyacente del paciente, tal como el metabolismo del paciente.
La parte 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 afección o enfermedad subyacente y/o cuán bien el modelo de paciente simula la reacción de la afección o 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 conjunto 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 parte 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 que 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 parte de aplicaciones básicas 54 como se describe anteriormente en el presente documento. Los ejemplos generales incluyen, pero no se limitan 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 se limitan 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 que 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 básicas que pueden ser accesibles por medio del módulo de análisis 76 pueden incluir, pero no se limitan 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 habilitan al sistema para realizar 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 una acción a una hora actual, a una hora futura o a horas determinadas por el análisis o a horas determinadas por el usuario final.
El módulo de conjunto 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 herramienta de este tipo 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 específica del paciente útil. A continuación, se puede usar la información fisiológica específica del paciente útil para desarrollar uno o más tratamientos para tratar la afección o 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.
En el documento US 2009/0006133 A1 se describe 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. Otra es la descrita en el documento US 2007/0179434 A1. 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 cualquiera de dichas otras herramientas de programa informático se contemplan por la presente divulgación.
La parte de módulos funcionales 56 del programa informático 50 (FIG. 2) incluye además un módulo de gestión de controladores del dispositivo 80 que proporciona acceso a uno o más controladores del dispositivo como se describe anteriormente en el presente documento con respecto a la parte de aplicaciones básicas 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 generar 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 dentro de 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 supervisió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 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
En 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 a continuación 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, a continuación, 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 requisitos definidos para los datos particulares que se han obtenido. Los ejemplos de dichos requisitos incluyen, pero no se limitan 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, con respecto a 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 requisitos 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 da mayores detalles sobre esta etapa se proporciona en una sección posterior. A continuación, 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í, a continuación, 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 similares. 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, a continuación, accediendo al sitio web correspondiente u otra fuente del enlace por medio de un navegador web convencional que forma parte de las aplicaciones básicas 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 la 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 analiza 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, por 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 ordenada manualmente. Para el estudio clínico, a la bomba se le proporciona un control por infrarrojos y se puede ordenar de una manera de bucle cerrado por 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:
h(t ) = - p ^ ) t a-1e- t / fsm\-1mm-1 (1).
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, @ 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:
^^L = - ; C 1+ / - rau (^ )h ( í-^ )d ^ (2).
El primer término —1c1 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 r (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 por 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. A continuación, 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¡)bservacl6n [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:
g=i(c,M-c,cObservación^ ^ 2
n (3),
donde c °bservación [/] es la concentración de insulina interpolada iésima en la franja 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 requisito 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 por el cuerpo de la aplicación. En este ejemplo, se puede usar una rutina de optimización llamada "fm/ncon" de un paquete de programa informático llamado MATLAB®, tal como llamar y proporcionar desde una de las aplicaciones básicas 54 (fig. 3). La función "fm/ncon" encuentra un mínimo limitado de una función de varias variables. A continuación, 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, r = 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 la FIG. 4, 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 parte 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 parte 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/o el 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 en el presente documento. 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 142 de validación del tratamiento 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 FIG. 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 partes 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 parte o partes 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/o el 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 ejemplo a continuación se presentará en el marco de las etapas ejecutadas 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 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 7,5, y actualmente es de 9,5. Bajo este patrón de hechos, se le indica al profesional sanitario que siga 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 supervisión intensiva completada. En este ejemplo, la selección es la visita regular. A continuación, el asistente solicita al usuario las introducciones de datos de seguimiento 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 horario de las comidas, composición de los carbohidratos, distribución de insulina, actividad física, patrón de sueño y horario de trabajo; criterios de exclusión; introducir estado fisiológico (afección, sin afección); introducir medicamentos; 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, a continuación, 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 de/es 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 y así sucesivamente. También se examina la serie temporal de datos 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 la correlación 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 las 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 una bG mínima para proporcionar recomendaciones útiles para lograr ese objetivo. Si la obtención de la medición de bG está por debajo del mínimo, a continuación, 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), la generación de las reglas empíricas da lugar a una 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 preprandiales 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 ahí 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, la pertinencia de esta recomendación, a continuació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, a continuación, 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, a continuación, 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 realizan, 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 incrementada, 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 que es mejor 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 preprandial 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. A continuación, 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 de nuevo para proporcionar suficientes datos para los parámetros del tratamiento iniciales necesarios para ajustar el tratamiento del paciente como un plan o receta de tratamiento recomendado. 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 formación, (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 preprandiales de bG por día para satisfacer el cumplimiento, se documentará el recuento de todos los carbohidratos ingeridos, la notificación en un dispositivo por insistencia del médico, guía de ayuda para el recuento de carbohidratos recomendada (o una clase de formación/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í, a continuación, el asistente repite la etapa 102 para los datos identificados. Si no es así, a continuación, 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 requisitos 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 modelo 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
Figure imgf000019_0001
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 la gestión de la enfermedad crónica del paciente. Además, con respecto a 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, con lo que los episodios hiperglucémicos se pueden reducir por 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, a continuación, indicando "no" en la etapa 144 da como resultado que el profesional sanitario pueda modificar una parte del tratamiento en la etapa 146. Después de realizar los cambios deseados en la etapa 146, a continuación, se repiten las etapas 140-144. De otro modo, el procedimiento 100 finaliza el tratamiento de recomendación generándolo 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 glucemia (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, se le indica al profesional sanitario que siga un protocolo de obtención de datos de supervisió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 supervisió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 dentro de 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 regular (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, mudarse 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 una 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, debido al cambio de zona horaria (pertinencia de un 25 %), (vi) alterar el tratamiento para ajustar la actividad física incrementada (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, aunque 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 detallada 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 la 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 para hacer un caso mixto bajo 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 por ordenador 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 a continuación 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 por ordenador 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 su acción.
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, a continuación, se comparan frente a uno o más intervalos esperados de las características del paciente observadas. Un objetivo en este punto es mantenerse dentro de 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 confianzas 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, a continuación, 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 por ordenador 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 supervisió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 de un 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 informáticas 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 mal gestionada. 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 por 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 dar 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. A continuación, 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 y usos de las mismas se proporcionan en lo sucesivo con referencia hecha a las FIGS. 2-9. Cómo el sistema y procedimiento responden a un acontecimiento se analiza en lo sucesivo.
Solicitar respuestas de programa informático por medio de un acontecimiento
Como previamente se menciona anteriormente 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) ordenar al dispositivo para que haga algo, (iv) informar a un paciente para que haga una tarea, (v) informar a un paciente de un estado fisiológico potencial y así sucesivamente. 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 original, 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 de la hora ú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 correlaciona la UTC con 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 a la hora 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 sobre 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 por la barra de progreso, la insulina distribuida a partir de la cantidad que se va a distribuir se podría mostrar como barra de progreso y así sucesivamente.
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: ordenar a una unidad de distribución de medicamentos (bomba de insulina) que distribuya medicamentos (insulina) con características de introducción de datos dadas; ordenar 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 dentro de 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 funcionan el sistema y el programa informático.
Ordenar 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 por medio del ordenador cliente 14. El acontecimiento por sí mismo se genera de una de muchas formas: (i) algoritmo, (ii) usuario, (iii) vigilancia (herramientas de terceros), (iv) protección en caso de fallo, (v) acontecimientos desencadenados por la base de datos y (vi) basado en protocolo. Las características necesarias únicamente para, y necesitarán, cubrir una duración de tiempo conocida o una desconocida antes de que se produzca la próxima comunicación. El horario de los medicamentos 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 ordenada, perfil de inyección intravenosa rápida para la comida). Cualquier actividad iniciada está limitada en general por una duración finita. Se entiende que la duración cubre la duración real del acontecimiento representado, ya que distribuir una inyección intravenosa rápida ordenada requiere físicamente un tiempo finito para la administración y esta duración puede ser pertinente para que el algoritmo la considere cuando decide la próxima orden 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.
Ordenar 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, el aviso de medición añade valor asistiendo al usuario, el profesional sanitario (PS) (por ejemplo, médico, RN, LPN o paramédico/EMT), el equipo de apoyo de urgencias con el momento 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 representado, 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 que el algoritmo la considere, 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 un tiempo desde el tiempo de medida deseado. Puede representar una secuencia de tiempo para la medición para los requisitos de medición basados en protocolo o basados en acontecimientos que pueden consistir en una secuencia de mediciones en duraciones de tiempo especificadas. 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 la hora de las mediciones y aún no se hayan producido las mediciones, se puede proporcionar fácilmente lógica para gestionar las futuras entradas y/o la entrada que falta. Por último, la cadena de avisos puede presentar la información tanto gráficamente como en formato 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 se necesita caracterizar los acontecimientos para obtener un mejor rendimiento. Actualmente, las comidas por ejemplo, solo se utiliza el 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 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 una 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 adelantado puede potenciar además el rendimiento del controlador. El tratamiento con insulina basado en la insulina de acción anticipada se puede reducir o dosificar previamente. En general, para un ejercicio anticipado, la insulina basal se reduce y, además, el algoritmo generará un acontecimiento de ingestión de carbohidratos para mantener la glucosa dentro del 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. Así, en un nivel superior, cada módulo se puede ver como una superposición de efectos. Pero en el núcleo de cómo se maneja cada uno de los módulos no está restringido. Por tanto, la funcionalidad modular de alto nivel es como sigue: gestión y mantenimiento; supervisión e información sobre el estado; manejo de acontecimientos importantes; acciones de control básicas (fundamentales para proporcionar un control glucémico); y acciones correctivas.
Gestión y mantenimiento
Los módulos de gestión y mantenimiento son como sigue: inicialización/preparación; manejo de ciclo perdido; correlación 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 gestiona la información anterior, actual y futura. El manejo de ciclo perdido maneja el reinicio del procedimiento 100 o las llamadas del algoritmo que se omitieron por cualquier motivo como protección en caso de fallo. La correlación de acontecimientos correlaciona el conjunto de acontecimientos externos con el conjunto de acontecimientos internos. Los depósitos de insulina gestionan 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, aunque las introducciones de datos y salidas de datos son efectos netos 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 requerido durante la consideración del componente individual o efecto modular agrupado. Por tanto, por ejemplo, la anulación de insulina está invalidando 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. La gestión interna de inyecciones intravenosas rápidas proporciona inyecciones intravenosas rápidas de prealimentación que resultan de un acontecimiento de comida. La gestión interna de inyecciones intravenosas rápidas permite (i) la creación de acontecimientos internos y (ii) la agrupación de acontecimientos internos. De este modo, la gestión 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.
Supervisión e información sobre el estado
Los módulos para supervisar 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, protección en caso de fallos y gestores de acontecimientos importantes. La actualización de glucosa hace un seguimiento de 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 órdenes 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 supervisión e información. El aviso de protocolo informa al usuario de la actividad próxima o pendiente generando acontecimientos internos. La protección en caso de fallos informa sistemáticamente a un respondedor (por ejemplo, un progenitor o servicio de vigilancia) de que el usuario está apagando el dispositivo o sistema y configura alarmas para crear franjas 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, a continuación, se proporciona como ayuda una teleasistencia de urgencia o formas alternativas para comunicarse. Los gestores de acontecimientos importantes son módulos para manejar acontecimientos importantes, tales como preparación para ejercicio, ejercicio, inyección intravenosa rápida ordenada y compensador de comidas. La preparación para ejercicio revisa el requisito 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, a continuación, regresa a su punto fijo de glucosa. La inyección intravenosa rápida ordenada es una petición para una inyección intravenosa rápida de insulina adicional (control del usuario) y permite una orden asíncrona. El compensador de comidas informa al controlador de la ingestión de carbohidratos. El estado alternativo/acontecimientos de desencadenamiento cubren el estado alternativo y los acontecimientos de desencadenamiento.
Acciones de control básicas
Los módulos de acciones de control básicas forman las acciones de control básicas fundamentales para proporcionar un control glucémico y son como sigue: procesamiento de 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. El procesamiento de datos del sensor determina un valor de glucosa a partir de valores de glucosa medidos disponibles, por ejemplo, valores de 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 utilizando los valores de medición de glucosa anteriores, 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 puede ser glucosa medida o 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/glucosa objetivo 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 maneja 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 maneja 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, a continuación, se seleccionan los parámetros determinados, de lo contrario se utiliza dicho conjunto de parámetros basados en la población subóptimo 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 ordenada 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 pasa 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 bajo nivel 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, órdenes 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 específicas del sistema, procedimiento y módulos de programa informático descritos anteriormente.
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 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 del 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 la gestión 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án directamente relacionadas con el ALGO 510 controlador. La secuencia de acontecimientos en el sistema por un periodo del ciclo de control Tc 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 -Ta), el a Ps 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, a continuación, 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, a continuación, 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 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, a continuación 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 APS 502 esperará la introducción de datos hasta que expire 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. A continuación, 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 requisito umbral, de lo contrario sería 0. La segunda llamada de ALGO se llama una llamada SYNC-2. Obsérvese que el requisito 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 orden final al APS 502 para la secuencia de acontecimientos I, y, a continuación, el APS 502 emite una orden 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 el funcionamiento clave del ALGO 510. Es crítico para el tratamiento que las dosis se proporcionen de manera fiable y oportuna. En las siguientes secciones a continuación, se abordan los siguientes aspectos del ALGO 510: aspectos de 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 maneja 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 llama a 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 y así sucesivamente. 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 glucemia 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 glucemia al día; ajuste de insulina, ingesta de alimentos y niveles de actividad en base a los resultados de las pruebas sobre la glucemia; asesoramiento dietético; y gestión por un equipo de diabetes. El EA 518 extiende este principio supervisando 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, intervenciones y así sucesivamente. 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. Un procedimiento de arquitectura abierta adecuado de este tipo se describe en el documento u S 2009/00057281 A1.
Como se usa en el presente documento para definir partes 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
Figure imgf000029_0001
Figure imgf000030_0001
Aspectos de horario
Como se menciona, APTS es un sistema en tiempo real donde el horario es 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 modo que no tenga sentido real del horario, sino que use 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 por la selección de un periodo del ciclo de control Tc. 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 horario 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 T0 representa la hora en la 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 ciclo késimo actual. Cada periodo del ciclo de control Te tiene un par de límites de control, un tiempo de inicio ts y un tiempo de finalización te. A cualquier hora relativa t dada, el ALGO 510 determina a qué periodo del ciclo de control Te pertenece la llamada actual 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 Te, sino que, más bien, dentro de cierta precisión temporal sobre el límite de control del tiempo de inicio ts. El término Ta es una desviación del tiempo del 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 una 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 ordenada 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 para recomendación y la ventana de confirmación con respecto al límite del tiempo de inicio ts del periodo del ciclo de control Te.
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 sistema para borrar el efecto de una introducción de datos. Si la duración de la actividad de la insulina es T¡) minutos, entonces, como viene dada por la ecuación (4):
n = ceil ( ^ ) , (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, nn se define como la suma de n y el número máximo de ciclos perdidos esperados. El intervalo necesario (y suficiente) para gestionar el ALGO 510 es mantener el historial durante nn 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 al ALGO 510. Si el APTS 500 completo fuera perfecto, se llamaría al ALGO 510 en cada periodo del ciclo de control Te. 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 pasada al ALGO 510 no tenga discrepancias. Al manejar esta situación, el ALGO 510 determina en primer lugar si se perdió una llamada. Si no se encuentra una llamada perdida, a continuación, 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. En 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 aparición de los acontecimientos conocidos. La información de estos acontecimientos puede estar disponible para el ALGO 510. Un gestor de acontecimientos 614 proporciona una correlación apropiada entre descripciones de acontecimientos externos con una pauta de acontecimientos internos. ALGO 510 desencadena los módulos apropiados para manejar las perturbaciones conocidas, que incluyen al menos uno de un módulo de orden de insulina 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 manejan 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 conmuta 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 basa en 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 gestión del depósito de bucle cerrado 630 determina y gestiona 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 hacen la distinción entre una recomendación de insulina gestionada 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 por 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 por el uso de un acontecimiento de inyección intravenosa rápida ordenada. Este es un control de bucle abierto, y el tratamiento se gestiona 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 ordenada 616 y el módulo de intervención de alto contenido de glucosa 618. Estos módulos posibilitan al sujeto o al profesional sanitario gestionar el tratamiento y administrar inyecciones intravenosas rápidas de insulina. El acontecimiento compensador de comidas 620, el acontecimiento 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 maneja 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. Se presenta solo para propósitos ilustrativos y se puede ordenar de una serie de formas en otros modos de realización. 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 básicas (fundamentales para proporcionar un control glucémico)—, "B" —gestión y mantenimiento (nivel superior)—; "C" —supervisión e información sobre el estado—; D —"acciones correctivas"— y "E" —manejo de acontecimientos importantes—. En lo sucesivo se proporciona un análisis general sobre cada uno de estos grupos de módulos.
Acciones de control básicas
Los módulos para las acciones de control básicas, fundamentales para proporcionar el control glucémico son: procesamiento de 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. El procesamiento de 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 a partir de los últimos valores de medición 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 maneja un nivel de actividad física incrementado. La ingestión de carbohidratos de acción rápida 824 maneja 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).
Gestión y mantenimiento (nivel superior)
En el nivel superior del funcionamiento de ALGO 510 están los problemas relacionados con la gestión y mantenimiento. Los módulos de gestión y mantenimiento son: inicialización/preparación 800, manejo de ciclo perdido 801, correlación de acontecimientos 802, depósitos de insulina 848 y anulación de insulina 836. El módulo de inicialización/preparación 800 es el vector de estado de ALGO que gestiona la información anterior, actual y futura (memoria de ALGO). El módulo de manejo de ciclo perdido 801 que se ha analizado anteriormente en una sección previa maneja el reinicio de las llamadas de APTS o ALGO que se omitieron por cualquier motivo. La correlación de acontecimientos 802 correlaciona el conjunto de acontecimientos externos con el conjunto de acontecimientos internos. Los depósitos de insulina 848 gestionan la recomendación de insulina de diversos módulos como componentes para llenar y vaciar los depósitos. La anulación de insulina 836 invalida 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. La gestión interna de inyecciones intravenosas rápidas 844 proporciona las inyecciones intravenosas rápidas de prealimentación que resultan de un acontecimiento de comida.
Supervisión e información sobre el estado
Los módulos para supervisar e informar sobre el estado son: Actualización de glucosa 808 que hace un seguimiento de 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 órdenes 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 circuito 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 ordenada frente a la insulina administrada.
Gestores de acontecimientos importantes
Los módulos para manejar los acontecimientos importantes son: Preparación para ejercicio 828 e inyección intravenosa rápida ordenada 830. La preparación para ejercicio 828 revisa el requisito 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 ordenada 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.
Correlación de acontecimientos
Después de ejecutar los módulos de inicialización y preparación y de manejo de ciclo perdido 800 y 801, a continuación, el ALGO 510, a continuación, ejecuta el módulo de correlación 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 correlaciona con como máximo un acontecimiento interno. Se proporcionan a los acontecimientos externos descriptores para que el usuario final se relacione con ellos, y/o desencadenen 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 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
Figure imgf000034_0001
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 por el estilo de vida del sujeto y el que se usa para controlar el ALGO 510 son bastante diferentes. 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 necesarias para gestionar acontecimientos como las comidas y el ejercicio. Para determinar el perfil definido de ALGO, el EA 518 usa supervisió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 respaldo, 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
Figure imgf000034_0002
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 dada 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):
/ f l = /? (Gf l - G ? ) £ , (5), donde GB es un valor de glucosa objetivo, IB es una tasa de insulina para mantener un valor de glucosa de GB, Gf es un valor de glucosa definido en el conjunto basal para una hora dada del día, Zf es una tasa de insulina necesaria para mantener un valor de glucosa de Gf, y ^ 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.
10 muestra la tasa de insulina basal al mediodía como una función del punto fijo de glucosa cuando ^ = 0,1 U/h
10 mg/dl se define como una constante. La línea Y similar muestra lo mismo r para la tasa de insulina basal a medianoche, pero a un punto fijo inferior (0,8 frente a 1,3). Por favor, obsérvese, sin embargo, que la pendiente se exagera para mostrar esta relación insulina-glucosa y es solo un ejemplo ilustrativo.
Procesamiento de 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 procesamiento de 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 procesamiento de 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 un valor de glucosa y la hora 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 fiable y exacto. Se usa una de dos funciones de procesamiento 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 recientemente. 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 franja de tiempo de y8_ „K duración T e como ( tG- T c, t G]. Se informa de la media del/de los valor(es) de glucosa G [ K ] = 1 . Valor de glucosa en el índice Késimo para el ciclo késimo. 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, por 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 (g f = 0) se retiran, a continuación, de los datos sin procesar por el módulo de procesamiento de 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 franja de tiempo de duración Te se define como: (ti - Te,ti]. Se eligen los valores de glucosa disponibles en la ventana seleccionada y se selecciona la mediana: G[K] = m e d iana^,..., gf,..., g f, gf). Valor de glucosa en el índice Késimo para el ciclo késimo. La mediana del tiempo se computa y se devuelve como tG[K] = mediana(rf,..., r f ,... r f , r f ). Obsérvese que la mediana del tiempo tG[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, a continuación, 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 fundamental 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
A continuación, 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 con respecto a las órdenes 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 ordenar manualmente una inyección intravenosa rápida. Un aspecto de esto es que se ve cualquier inyección intravenosa rápida ordenada manualmente al inicio de cada ciclo de control en el término de insulina neta administrada. Puesto que el ALGO 510 no recomendó la inyección intravenosa rápida ordenada manualmente, el EA 518 considerará esta inyección intravenosa rápida como un excedente de dosis. A continuación, el excedente de insulina determinado se tiene en cuenta y se ajusta por retroalimentación durante las futuras acciones de control. Para manejar sistemáticamente este caso, se debe desencadenar un acontecimiento de inyección intravenosa rápida automática antes de la acción de la inyección intravenosa rápida manual. El ALGO 510 espera a continuación 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 ordenada. La inyección intravenosa rápida no resuelta tiene una franja de tiempo finita dentro de 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 ordene 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, a continuación, 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 franja de tiempo especificada, 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á por un subconjunto de funcionalidades expuestas. La tarea del módulo de glucosa desactualizada 814 es dar información con respecto al 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 conmuta 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 a ir a 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 a ir al 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í, a continuación, 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 ordenada determinada por EA 518 es diferente de la insulina distribuida desde la bomba. Si es así, a continuación, el EA 518 marca esto como una discrepancia en la insulina ordenada y presenta una notificación al usuario en la interfaz de usuario 512 (FIG. 5). A continuación, se necesita resolver la discrepancia entre la insulina ordenada 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
A continuación, el EA 518 procede al módulo de zona de glucosa de la comida 820. En este punto, el módulo de 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 su lugar, 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 delimitada 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) dentro de 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) Dentro de la zona de glucosa
Si el valor de glucosa predicha se encuentra dentro de los límites de la zona de glucosa, entonces, la glucosa del sujeto se considera dentro de 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, se considera que al sujeto se le ha administrado poca 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 de 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 de 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 maneja 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.
Preparación para ejercicio 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 requisito 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 tras el 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 esperada, ya que la glucosa se almacena como glucógeno en los músculos y el hígado. En consecuencia, el ejercicio se maneja en fases por los módulos de ejercicio y preparación para ejercicio 822 y 828, de manera receptiva.
El módulo de preparación para ejercicio 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 manejar 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 gestionar 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 preparación para ejercicio 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):
AGT = —AGE (6),
donde AGr es el cambio del valor de glucosa objetivo, y AGp 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):
Gp = Gp + AGT (7).
De nuevo, una vez que comienza la actividad de ejercicio, el cuerpo puede necesitar menos insulina y puede mantener un requisito 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 la preparación para ejercicio. El estado basal se evalúa de nuevo al principio del acontecimiento de ejercicio. Si la preparación para ejercicio no elevó el nivel de glucosa a la cantidad deseada, a continuación, 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:
AGp=AGP+KjjAGE (8),
donde AGP se usa, a continuación, para computar la insulina basal necesaria (es decir, la subida de glucosa). Obsérvese que K E 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 requisito del conjunto basal. En esta implementación, la duración del ejercicio está definida previamente en el vector AGE. Una vez que el ejercicio se haya acabado, la subida de glucosa debida al ejercicio AGE es 0. La discontinuidad se atenúa usando KE =factor de recuperación, y TE = duración de la recuperación en minutos. Si la tasa basal de insulina del conjunto basal viene dada por I'B, a continuación, se puede determinar usando la ecuación (9):
IB = I'B( ( l - K Ey - - i KE (9), d o n d e t F e s la h o ra a la q u e se c o m p le tó e l e je rc ic io , y t e s la h o ra a c tu a l.
C a r b o h i d r a t o d e a c c i ó n r á p i d a
D e s p u é s d e te rm in a r co n e l m ó d u lo d e e je rc ic io 822 , a c o n t in u a c ió n , e l E A 815 lla m a a l m ó d u lo d e c a rb o h id ra to s d e a c c ió n rá p id a 824 p a ra p ro p o rc io n a r u n a a c tu a liz a c ió n d e un v e c to r d e s u b id a d e g lu c o s a d e b id o a u n a in g e s tió n d e c a rb o h id ra to s d e a c c ió n rá p id a s i a s í se in d ic a p o r e l p a c ie n te e n la in te r fa z d e u s u a r io 512 (F IG . 5).
F C
El v e c to r d e s u b id a d e g lu c o s a A G s e a n a liz a u s a n d o un p e rf il d e s u b id a d e g lu c o s a e s p e ra d o y un p e rfil d e s u b id a d e g lu c o s a re la tiv o . E l p e rf il d e s u b id a d e g lu c o s a e s p e ra d o e s un v e c to r d e s u b id a d e g lu c o s a p re d e fin id o , y s e n o rm a liz a p o r g ra m o d e in g e s ta d e c a rb o h id ra to s y p o r a u m e n to e n m g /d l. E l v e c to r d e s u b id a F C
d e g lu c o s a re la t iv o e s e l p ro d u c to d e l v e c to r d e s u b id a n o rm a liz a d o A G , la c a n t id a d d e c a rb o h id ra to s d e a c c ió n rá p id a c o n s u m id o s e n A F C [g ], y e l a u m e n to d e g lu c o s a e s p e ra d o p o r g ra m o d e c a rb o h id ra to K j j G [m g /d l/g ]. P o r ta n to , e l v e c to r d e s u b id a d e g lu c o s a s e p u e d e d e s c r ib ir y d e te rm in a r p o r la e c u a c ió n (10 ):
A G P — A G P A F C K j j c . ^ AG /¡C[¿]
l — K
(10 ).
I n t e r v e n c i ó n d e b a j o c o n t e n i d o d e g l u c o s a
L u e g o , e l E A 518 lla m a a l m ó d u lo d e in te rv e n c ió n d e b a jo c o n te n id o d e g lu c o s a 826 q u e m a n t ie n e la s e g u r id a d d e l u s u a r io d e f in ie n d o la s c o n d ic io n e s q u e a s e g u ra n e l a u m e n to d e l v a lo r d e g lu c o s a . E n u n a s itu a c ió n d e b a jo c o n te n id o d e g lu c o s a , ta l c o m o c u a n d o A L G O 510 no h a lo g ra d o m a n te n e r e l n iv e l d e g lu c o s a p o r e n c im a d e un lím ite g lu c é m ic o a c e p ta b le d e m a n e ra o p o rtu n a , e l E A 518 in te rv e n d rá e n b a s e a la in fo rm a c ió n p ro p o rc io n a d a a p a r t ir d e e s te m ó d u lo . E l p ro p ó s ito d e e s ta in te rv e n c ió n e s d e v o lv e r a l s u je to a un in te rv a lo g lu c é m ic o n o rm a l p o r la in g e s tió n d e c a rb o h id ra to s d e a c c ió n rá p id a . C o n e l E A to d a v ía a c t iv o , e l A L G O 510 v e rá e l in c re m e n to d e la g lu c o s a m e d id a y p o te n c ia lm e n te c o n tra r re s ta rá e s ta s u b id a d e g lu c o s a re c o m e n d a n d o in s u lin a a d ic io n a l. S in e m b a rg o , e l m ó d u lo d e in te rv e n c ió n d e b a jo c o n te n id o d e g lu c o s a 826 p e rm ite q u e la g lu c o s a a u m e n te c o n u n a re c o m e n d a c ió n d e in s u lin a m á s c o n s e rv a d o ra .
E n un m o d o d e re a liz a c ió n , A L G s e d e f in e c o m o la c a n tid a d d e c a rb o h id ra to s d e a c c ió n rá p id a n e c e s a r ia p a ra re d u c ir e l n iv e l d e g lu c o s a . A c o n t in u a c ió n , la s u b id a d e g lu c o s a e s p e ra d a v ie n e d a d a p o r la e c u a c ió n (11 ):
AG¿g — A G j i G A l g K p C
(11),
d o n d e A G p G e s la s u b id a d e g lu c o s a d e b id a a la in g e s ta d e c a rb o h id ra to s d e a c c ió n rá p id a , A L G e s la c a n t id a d d e c a rb o h id ra to s d e a c c ió n rá p id a p a ra la in te rv e n c ió n d e b a jo c o n te n id o d e g lu c o s a , K p C e s e l a u m e n to d e g lu c o s a p o r g ra m o d e c a rb o h id ra to s . L a F IG . 14 m u e s tra g rá f ic a m e n te la s u b id a d e g lu c o s a p a ra la in g e s ta de c a rb o h id ra to s d e a c c ió n rá p id a . M o d if ic a n d o e l p u n to f ijo d e g lu c o s a G sp e n u n a c a n t id a d ig u a l a l a u m e n to e s p e ra d o A G p ° , e l A L G O 510 n o c o n tra r re s ta rá e l a u m e n to a tr ib u id o a la in g e s ta d e c a rb o h id ra to s d e a c c ió n rá p id a . A d e m á s , f in a lm e n te , se d e b e re e s ta b le c e r G sp a l p u n to f ijo o r ig in a l. E l v e c to r d e s u b id a p a ra e l p u n to f ijo s e d e fin e c o m o un p ro d u c to d e A G p G y e l té rm in o d e g a n a n c ia lin e a lm e n te d e s c e n d e n te ( l - ^ r ) , y v ie n e d a d o p o r la e c u a c ió n (12 ):
_,mín (j+1,len(AGFC))
a g gg [j ] — ( i - í± ) a ggk fg£ Z A G FP C [i] (12).
P o r ta n to , e l p u n to f i jo v ie n e d a d o d e a c u e rd o co n la e c u a c ió n (13 ):
G S P = G S P A G $ p ( 13 ) .
L a F IG . 15 m u e s tra g rá f ic a m e n te e l c a m b io d e l p u n to f ijo re la t iv o a lo la rg o d e l t ie m p o . E s p o s ib le q u e se p ro d u z c a n m ú lt ip le s in te rv e n c io n e s d e b a jo c o n te n id o d e g lu c o s a c u a n d o la g lu c o s a n o a u m e n ta lo s u f ic ie n te m e n te rá p id o . E s to ta m b ié n d a lu g a r a u n a a c u m u la c ió n d e G sp d e b id o a lo s m ú lt ip le s a c o n te c im ie n to s d e in te rv e n c ió n d e b a jo c o n te n id o d e g lu c o s a . L a in te rv e n c ió n d e b a jo c o n te n id o d e g lu c o s a , e n lu g a r d e a ñ a d ir lo s e fe c to s , e lim in a la p a rte p e n d ie n te re s ta n te d e la ú lt im a in te rv e n c ió n d e b a jo c o n te n id o d e g lu c o s a a n te s d e a ñ a d ir e l A G p G p a ra e l a c o n te c im ie n to d e in te rv e n c ió n d e b a jo c o n te n id o d e g lu c o s a a c tu a l. D e s p u é s d e d ic h a in te rv e n c ió n , e l E A 518 lla m a a l m ó d u lo d e p re p a ra c ió n p a ra e je rc ic io 828 , q u e , p u e s to q u e s e a n a liz a a n te r io rm e n te en la s e c c ió n p re v ia t i tu la d a "P re p a ra c ió n p a ra e je rc ic io y e je rc ic io " , n o s e p ro p o rc io n a n in g ú n o tro análisis.
Inyección intravenosa rápida ordenada
El EA 518 usa el módulo de inyección intravenosa rápida ordenada 830 cuando el usuario ordena 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 ordenada 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 ordenada 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 ordenada ACB estará por encima de la cantidad de insulina requerida necesaria 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 ordenada 830 posibilita al sujeto gestionar 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 habilita al EA 518 para corregir 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 ordenada es insulina "vista por ALGO", mientras que la insulina administrada para cubrir un acontecimiento de intervención de alto contenido de glucosa es "no vista por ALGO". En el modo de control puro 600 de bucle cerrado, la cantidad de intervención con respecto a la insulina está oculta para la parte de retroalimentación del ALGO 510. El módulo de anulación de 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 pudo 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 a la hora tM y de cantidad AM. En segundo lugar, un acontecimiento de corrección en la comida a la hora tMC y de cantidad se ha introducido por el usuario. En un modo de realización alternativo, el acontecimiento de comida se define como la comida restante A™. Si se cumplen ambas condiciones, a continuación, 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):
donde T™ es el tiempo en minutos y es la franja de tiempo permitida para corregir la entrada de la última comida, y 0 — A y —AM (solo para el caso de comida restante). Si se satisface la última condición anterior, a continuación 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 el otro procesamiento, el módulo 834 reemplaza la distribución de insulina obtenida para AM a la hora tM por la nueva distribución de insulina computada para la nueva cantidad de com ida^. La distribución se implementa con respecto a la hora tM y no con respecto a tMC. Para el caso de comida restante A^,A¡^ viene dada por la ecuación (15):
a m = a m - A m (15).
El módulo 834 identifica el último acontecimiento de comida que se produce a la (a) hora en la que se produjo y (b) la cantidad. Si se satisfacen los supuestos 1 y 2, los cálculos del módulo: Para A¿ encontrar la distribución de insulina. Desplazar la hora de la distribución a la hora en la que se produjo la última comida. Para AM encontrar la distribución de insulina. Desplazar la hora de la distribución a la hora en la que se produjo la última comida. A partir de los lapsos de tiempo correspondientes realizar: Del vector de INYECCIÓN INTRAVENOSA RÁPIDA RELACIONADA CON LA COMIDA, restar A¿ la distribución de insulina relacionada y añadir la distribución AM. Del vector de ACONTECIMIENTO INTERNO DE INYECCIÓN INTRAVENOSA RÁPIDA, restar A¿ la distribución de insulina relacionada y añadir la distribución AM. Este otro procesamiento del módulo de rectificación de carbohidratos 834 se aclara además por 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, a la hora tM = 495 se introduce un acontecimiento de comida de 100 g que necesita [205003002] como distribución de insulina. INYECCIÓN INTRAVENOSA RÁPIDA RELACIONADA CON LA COMIDA hasta que t=525 sea [3 1 5] 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 a 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. A tM c=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 a tM =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,503002000 1,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 [205003002] en la etapa 6. Ambos vectores (60 g y 100 g) se desplazan a t=500 en la etapa 7 (mostrado por 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, a continuación, se presenta uno de los siguientes mensajes emergentes (dependiendo de las cantidades introducidas): "ADVERTENCIA: La comida de (cantidad en número) gramos introducida a (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 insulina
Después del módulo de rectificación de carbohidratos 834, el EA 518 llama al módulo de anulación de insulina 836. Como se menciona anteriormente, el módulo de anulación de insulina 836 invalida 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 orden 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 insulina elimina cualquier cantidad de insulina de prealimentación de la administración de insulina final. La implementación actual de EA 518 gestiona diversos componentes de la insulina de prealimentación por separado. La anulación de 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. El vector de insulina anulada fN viene dado por la ecuación (16):
fN = r - r v - i s
(16),
donde I es un vector de insulina administrada, ív es una inyección intravenosa rápida relacionada con la comida y de intervención de alto contenido de glucosa, Is 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 de 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 en el archivo subject.ini y viene dada aquí por l r . 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 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 proporciona el control basal, en conjunto 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 a una hora actual, el módulo de predicción de glucosa 838 usa la siguiente información. Valor de glucosa procesada, G[K] y el tiempo procesado correspondiente, íg[K\. Información de insulina anulada, /[_n:_i|j] durante los últimos Td minutos con respecto a j, donde Td es la duración del efecto de la insulina. Si Te es el periodo de control, entonces, Td = riTc. Obtener la farmacodinámica de la insulina, l r . Se supone que la caída de glucosa es directamente proporcional a la insulina utilizada, AG[í] k AIr [i] donde i = 1,2,...,n. Se obtiene la insulina utilizada Al r para una inyección intravenosa rápida unitaria como la diferencia progresiva realizada sobre el vector l r . El vector Al r viene dado por la ecuación (17):
Alr [í] = l r [i 1 ] - l r [í],i = 1,2.....n - 1 (17).
La FIG. 18 muestra gráficamente los cambios en la insulina utilizada Al r 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:
AG[í] = —K[Alr [i]
(18).
El vector de caída de glucosa se define por la ecuación (19) como:
A G = -K¡AIr
(19).
Para predecir la caída de glucosa en el tiempo 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 inyecciones intravenosas rápidas de insulina anulada con I[-n:-1i¡] con AG que se define por la ecuación (20) como:
AG[j] = í - n - i i j ] * AG = Z l=i ( l [- n+liJ]AG[n - r]) (20),
donde f[-n:-1if] es el vector de las últimas r cantidades de insulina administradas con respecto al punto j, la caída de glucosa, AGj] 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 para algún 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 es la administración de insulina anulada. La caída de glucosa esperada, AGNj] se define por la ecuación (21) como:
AGN[ j ] = í - n- i i j ]*AG, j = K 1..... k
(21).
(b) Insulina basal definida previamente
La insulina basal definida previamente se determina a partir del conjunto basal y es el valor de "insulina basal potencial", ¡f-n.-1if] 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:
AGs[ / ]= / f - n:- i U]*AG, j = K 1......k
(22).
(c) Predicción de glucosa
A continuación, dado el valor de glucosa G[/] en la etapa jés¡ma, entonces, la glucosa predicha G[/+1] viene dada por la ecuación (23) como:
G[¡ + 1] = G[/] AGB[j] — AGw[/] AGP\i 1]
(23),
donde, A GP[¡ 1] es la subida de glucosa estimada a partir de una perturbación conocida. A continuación, la predicción de glucosa se transfiere desde el último valor de glucosa conocido a la hora ík con respecto a la hora actual, tk. A continuación, 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
Figure imgf000043_0001
_________
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, a continuación, 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 normal = 50 g y comida abundante = 75 g. Si la petición de insulina basal actual es relativa y se ha desencadenado una comida, a continuación, 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, a continuación, se fija una marca que controla el módulo de aviso de comidas 842 por el controlador basal 628.
Gestión interna de inyecciones intravenosas rápidas
Adicionalmente, si procede, el EA 518 llama a la gestión interna de inyecciones intravenosas rápidas 844 para administrar las inyecciones intravenosas rápidas de prealimentación 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 I¡-n.-1 |fe] es la administración de insulina anulada. A continuación, la insulina estimada restante es / " [k] viene dada por la ecuación (24) como:
/rw[fc]= /]-n:- i W *A/r
(24).
(c) Punto fijo de glucosa
Esta es la glucosa objetivo y viene dada por Gt.
(d) Insulina basal definida previamente
Esta se determina a partir del conjunto basal y es el valor "insulina basal potencial", Z®. Este es el componente de insulina basal requerido para mantener la glucosa objetivo, Gt. La insulina esperada restante, /®[k] viene dada por el producto interior definido por la ecuación (25) como:
I?[k] = /£ * AIr
(25).
(e) Subida de glucosa
La subida de glucosa viene dada por AGp. En consecuencia, la recomendación de insulina, viene dada, a continuación, por Ireq como se define por la ecuación (26) como:
, estimada ^ j)
req = K,
(26),
donde la Gestimada viene dada por la ecuación (27) como:
êstimada = G[k] [-K ,(I¡f[k] - I?[fc])] + AGp
(27),
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 requisito 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 solo un único punto, por ejemplo, permítase que Gpí£o y Gja>0 definan los puntos fijos superiores e inferiores, respectivamente. Si la glucosa estimada Gestimada está dentro de la zona objetivo, entonces, la Ireq simplemente es insulina basal. Para el caso de requisito 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 requisitos 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, a continuación, ALGO 510 evalúa de nuevo y contabiliza de nuevo los componentes con respecto a la administración de insulina final revisada en consecuencia.
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 cualquiera de dichas condiciones es falsa, a continuación, 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, a continuación, el EA 518 llamará al módulo de gestión de discrepancias 818, al modelo de ordenar inyección intravenosa rápida 830, al módulo de intervención de alto contenido de bG 832 y a un módulo de limitación del tope de administración 852 que impone limitaciones a las recomendaciones de insulina final. Al finalizar estas llamadas, a continuación, el EA 518 llamará al módulo de actualizar almacenamiento 854 para guardar el valor y las condiciones de este ciclo de control. A continuación, 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, PatientlniStruc). 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, yTrace 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. A continuación, 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. Véase 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
Figure imgf000045_0001
Figure imgf000046_0001
EventStruc - Estructura del acontecimiento
Esta es una estructura que contiene la programación de desencadenamiento 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. Véase la tabla 7 para los campos de la estructura del acontecimiento.
Tabla 7: Campos EventStruc
Figure imgf000046_0002
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 es preexistente. 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 el tiempo de la simulación actual. Al menos uno del tiempo de desencadenamiento 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 tiempos, ALGO 510 no puede juzgar cuándo se produjo ese acontecimiento particular y lo ignorará. Las entradas de event_type son las enumeradas por la estructura de "patientini.events" y tienen los campos de tipo, unidades y Nombre interno.
Pueden variar de un experimento a otro 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. Véase la tabla 8 para los campos de la estructura del experimento.
Tabla 8: Campos de la estructura del experimento
Figure imgf000047_0001
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 pasa inicialmente como un parámetro. En la fase de inicialización, PumpStruc se convierte en un archivo mat. a Ps 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. Véase la tabla 9 para los campos de la estructura de la bomba.
Tabla 9: Campos PumpStruc
Figure imgf000048_0001
Figure imgf000049_0001
BGStruc - Estructura de la glucemia
Excepto 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 pasa 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 da 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 la siguiente correlación para sensores: 0 para "EXT"; 1 para "SU 1"; y 2 para "SU 2".
Tabla 10: Campos de la estructura del sensor
Figure imgf000049_0002
Figure imgf000050_0001
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 glucemia (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. Experimento son los datos obtenidos desde el principio al fin del APTS, incluyendo cualquier reinicio intermedio y cambio de los archivos INI. Véase la tabla 11 para las descripciones del campo proporcionado en el archivo INI del sujeto.
Tabla 11: Campos PatientIniStruc
Figure imgf000050_0002
Figure imgf000051_0001
Variables de salida de datos
El término yAMT es un vector de órdenes de la bomba y presentación, y contiene órdenes para la bomba. La tabla 12 proporciona detalles sobre las órdenes contenidas en el vector de órdenes yAMT.
Tabla 12: vector yAMT
Figure imgf000051_0002
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: de 00 a 09), (2) emerge una ventana de mensaje (intervalo: de 10 a 98) y (3) salir/abandonar (intervalo 99). El término yTrace es una cadena de señales que hace un seguimiento de las etapas de la ejecución de ALGO. El progreso de ALGO se registra en un archivo de registro 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 no sincronizadas, cada valor ordenado se limita a la cantidad que la bomba puede distribuir en la parte 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 ordenada y aparece cuando el profesional sanitario acepta o rechaza manualmente una recomendación de insulina. En un modo de realización ilustrado, esta ventana expira 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 al ALGO al inicio del ciclo de control. El ALGO procesará la introducción de datos y recomendará una cantidad que se ha de distribuir en la parte restante del ciclo de control. Pero existen limitaciones de equipo físico porque (1) cada acción dura un tiempo finito y (2) el reloj de tiempo 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 ordenado que permitirá la administración de la orden en total.
Tabla 13: Parámetros en ALGOSHELL
Figure imgf000052_0001
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 introducidos se muestran antes y después de la llamada "Sync1".
Situación de recomendación pura
Si m es la última llamada de ALGOSHELL 506 en control, entre la llamada mésima y la (m+1).a, BGStruc se actualiza con las nuevas mediciones. Estas mediciones se obtienen de la base de datos. Antes de la m+1.a 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 y se presentan mensajes apropiados (enviar a la ventana de registro, emerger un cuadro de mensaje y abandonar). 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á dentro del umbral de una o tres dosis, no se necesita confirmar por el profesional sanitario que se ha de infundir. 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 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. A continuación, 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 es todavía el relativo medido con referencia a "ExperimentsStruc.t_zero".
Tabla 14: Flujo de ALGO-APS
Figure imgf000053_0001
Figure imgf000054_0001
Los 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 registre y almacene 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, serán 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 informático técnico de MATLAB. En otros modos de realización, se pueden usar otros lenguajes y entornos informáticos, tales como visual basic y el sistema operativo Windows. La interfaz de usuario del lado del cliente 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 simulación, 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 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 esta segunda implementación de la memoria descriptiva.
Componentes de programa informático
La aplicación de APCATS comprende varios componentes de programa informático distintos 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 todos los lados del cliente 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 el lado del cliente que permite la introducción de datos por el 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 propio problema, 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 gestiona 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 glucemia 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 disponen 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 pasa 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 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 aparecerá 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. (Véase 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. (Véase 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 mínimos, máximos e intermedios igualmente espaciados n-2. 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 dar 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 más de un parámetro para que 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 conjuntamente bloques del dispositivo. El bloque de activador 920 (FIG. 22) simula una unidad de bomba que recibe órdenes 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 dispositivo 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 habilitan. 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 existe 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 el lado superior izquierdo. 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 con número más alto). Si el usuario decide conmutar 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 conmutar 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 de los 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 un 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 alterar. 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, de los que algunos 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 órdenes 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 enumerados. 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 desencadenar. 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. A continuación, el usuario procede a introducir los valores restantes en esa fila.
Cuando se desencadena, el acontecimiento desencadenado tan solo desencadena 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 desencadenamiento, mostrado como "Tiempo de inicio del acontecimiento"; "Tipo de acontecimiento"; tiempo de desencadenamiento 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). La hora de desencadenamiento relativa es con respecto a la hora del acontecimiento que se produce físicamente en la que el bloque de controlador 918 (es decir, ALGO 500) reconoce el acontecimiento desencadenado. Se puede informar al bloque de controlador 918 de la aparición: (a) antes de que se produzca el acontecimiento real (número negativo); (b) simultáneamente con la aparición 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 órdenes 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 se 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 "SELECCIONAR OPCIONES DE DIETA Y EJERCICIO", 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 apariciones.
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 órdenes 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 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 necesitan 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 pasan 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 gestiona 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 dentro de 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 a la salida de datos en el cuadro de edición adyacente al campo de introducción de datos que ha de recibir la salida de datos. 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 usarán como introducción de datos 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 de 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áneosubcutá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 detalles 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 un 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 un 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 escriben en un archivo temporal en el área de trabajo. Si APCATS 900 falla, a continuación, las configuraciones guardadas en este archivo se pueden reestablecer haciendo clic en un botón Antiguos 1015 en el formulario de Entrada de inicio (FIG. 32), y buscando el archivo temporal en el directorio del archivo enumerado. Para que aparezca el formulario de Entrada de inicio 1010 en cualquier momento, hacer clic en el botón del FORMULARIO DE INICIO 1018. El formulario de 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 de APCATS" (no mostrado) que permite al usuario regresar al APCATS 900 y cancelar la orden de salida. Haciendo clic en el botón Continuar se procederá con el cierre 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 un 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 fijar 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 franja 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 construir modelo, una marca definida en el archivo init controla si un usuario puede o no construir y ver un modelo. Si está autorizado, el usuario puede hacer clic en el botón construir modelo 1032 para construir el modelo Simulink para el que se introdujo un nombre de archivo en el cuadro de texto nombre del modelo Simulink. A continuación, 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 desencadenará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 de registro mantenidos en una unidad de red. Haciendo clic en un botón de 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 bien 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 supervisar 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, posteriormente, 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 en 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 la 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 el primer y el último 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 se 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 seleccionar subgráfica 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 seleccionar subgráfica. 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 mostrar en gráficas de un cuadro de lista 1054 localizado justo 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 la primera y la última 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 encima de 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 la(s) gráfica(s) 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 por 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
Figure imgf000063_0001
DietInit.m
Figure imgf000063_0002
Figure imgf000064_0001
SensorInit.m
Figure imgf000064_0002
ActuatorInit.m
Figure imgf000064_0003
ControlInit.m
Figure imgf000064_0004
SenFailInit.m
Figure imgf000065_0001
ActFailInit.m
Figure imgf000065_0002
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.
Figure imgf000065_0003
Figure imgf000066_0001
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.
Figure imgf000066_0002
Figure imgf000067_0001
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.
Figure imgf000067_0002
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.
Figure imgf000068_0001
Archivo de simulación (mdl)
El siguiente ejemplo muestra un archivo de simulación (mdl) que, como se menciona anteriormente, se puede modificar como se desee por el usuario.
Figure imgf000068_0002
Figure imgf000069_0001

Claims (13)

REIVINDICACIONES
1. Un sistema (10) para determinar una administración de insulina y comunicar una dosis en el programa informático de páncreas automatizado APS (502), comprendiendo el sistema
un procesador (16, 34) que está configurado para ejecutar un controlador de algoritmo, ALGO, (510) y un módulo de algoritmo empírico, EA, (518) proporcionado en el controlador ALGO (510), en el que
- el controlador de algoritmo ALGO (510) pasa entradas de información, incluyendo la información de glucosa más reciente, la información de administración de insulina anterior y la información de acontecimientos que comprende al menos uno de comidas, ejercicio e intervención de un paciente, al módulo EA (518) para determinar una recomendación de tratamiento, y
- el módulo EA (518) proporciona la recomendación de tratamiento en base a las entradas de información,
caracterizado por que
a) el módulo EA (518) está estructurado como un grupo de módulos (800, 801, 802, 804, 806, 808, 810, 812, 814, 816, 818, 820, 822, 824, 826, 828, 830, 832, 834), manejando cada módulo un aspecto de la recomendación de tratamiento;
b) el módulo EA (518) comprende un compensador digital con un horario basado en índices independiente del tiempo real, que determina la cantidad de control apropiada en base
- al horario que existe en los índices de matrices de variables, y
- a una selección de un período de ciclo de control Tc para cada ciclo de control del controlador ALGO, en el que cada período de ciclo de control Tc tiene un par de límites de control en un tiempo de inicio ts y un tiempo de finalización te, respectivamente;
c) el controlador ALGO (510) comprende una descripción de horario que depende de una hora relativa t de ciclos de control transcurridos desde el inicio de un tratamiento TA0 implementado, en el que a cualquier hora relativa t dada, el controlador ALGO (510) determina a qué período de ciclo de control Tc pertenece una llamada actual al controlador ALGO (510) para una hora actual T, en el que la llamada al controlador ALGO (510) no está exactamente en el límite de control del tiempo de inicio ts del período del ciclo de control Tc, sino que, más bien, dentro de una precisión temporal dada sobre el límite de control del tiempo de inicio ts; y
d) el controlador ALGO (510) funciona en un modo de bucle cerrado (600), en el que el controlador ALGO (510) se dispone por sí mismo en un modo de bucle abierto (700) desde el modo de bucle cerrado (600) cuando existe tanto la no disponibilidad de una medición de glucosa debida al retardo de medición determinado por un módulo de actualización de glucosa (808) del módulo EA (518) como una medición de glucemia desactualizada, que se indica por un módulo de glucosa desactualizado (814) del módulo EA (518), si el último valor de medición de glucemia recibido es más antiguo que un determinada franja de tiempo especificada.
2. El sistema (10) de acuerdo con la reivindicación 1, en el que un periodo de tiempo durante el que se necesitan las entradas de información para computar una recomendación de insulina para el controlador ALGO (510) depende de la duración para borrar un efecto de una actividad de insulina más varios ciclos de control adicionales como una memoria intermedia para cubrir los ciclos de control perdidos en el que un ciclo de control perdido es el período de ciclo de control en el que no se llama al controlador ALGO (510).
3. El sistema (10) de acuerdo con la reivindicación 2, en el que en el caso de un ciclo de control perdido, el controlador ALGO (510) tras llamarse detecta las llamadas perdidas y recorre cada uno de los ciclos de control perdidos antes de ejecutar una llamada actual.
4. El sistema (10) de acuerdo con una cualquiera de las reivindicaciones precedentes, en el que el modo de bucle abierto se gestiona e implementa manualmente a través del uso de una tasa basal de bomba programada previamente del paciente y se aumenta por el uso de un acontecimiento de inyección intravenosa rápida ordenada, y en el que la entrada de una nueva medición de glucosa habilita al controlador ALGO (510) para funcionar en modo de bucle cerrado después de conmutar al modo de bucle abierto.
5. El sistema (10) de acuerdo con una cualquiera de las reivindicaciones precedentes, en el que en el modo de bucle cerrado (600) el controlador ALGO (510) usa mediciones de glucosa para desencadenar al menos uno de un módulo de ordenar insulina (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) y un módulo de compensador de bajo contenido de glucosa (624) para manejar perturbaciones conocidas, y al menos uno de un predictor de glucosa (626) y un controlador basal (628) para manejar perturbaciones desconocidas y errores de modelado para mantener la glucosa en una zona objetivo (601) predeterminada que está delimitada por límites de glucosa objetivo superior e inferior.
6. El sistema (10) de acuerdo con la reivindicación 5, en el que el módulo de compensador de comidas (620), el módulo de compensador de ejercicio (622) y el módulo de intervención de bajo contenido de glucosa (624) no se ejecutan en el modo de bucle abierto (700).
7. El sistema (10) de acuerdo con una cualquiera de las reivindicaciones precedentes, en el que el módulo EA (518) comprende además módulos para acciones de control básicas que incluyen un módulo de procesamiento de datos del sensor (806), un módulo de punto fijo de insulina (804), un módulo de predicción de glucosa (838), un módulo de recomendación de insulina (846), un módulo de compensador de ejercicio (822), un módulo de ingestión de carbohidratos de acción rápida (824), un módulo de compensador de comidas (840) y un módulo de lógica de implementación basal de bucle abierto (850), en el que módulo de procesamiento de datos del sensor (806) determina un valor de glucosa a partir de los valores de glucosa medidos disponibles, el módulo de punto fijo de insulina (804) es una tasa de infusión de insulina usada para mantener la glucosa basal objetivo, el módulo de predicción de glucosa (838) predice el valor de glucosa para ciclos de control a partir de los últimos valores de medición de glucosa conocidos, el módulo de recomendación de insulina (846) computa la dosis de insulina para mantener la glucosa basal, el módulo de compensador de ejercicio (822) maneja un nivel de actividad física incrementado, el módulo de ingestión de carbohidratos de acción rápida (824) maneja la ingestión de carbohidratos de acción rápida para compensar una caída de glucosa esperada, el módulo de compensador de comidas (840) computa la distribución de inyecciones intravenosas rápidas de insulina para un acontecimiento de comida, y el módulo de lógica de implementación basal de bucle abierto (850) implementa insulina basal durante el modo de bucle abierto (700).
8. El sistema (10) de acuerdo con una cualquiera de las reivindicaciones precedentes, en el que el módulo EA (518) comprende además módulos para gestión y mantenimiento que incluyen el módulo de inicialización/preparación (800), el módulo de manejo de ciclo perdido (801), el módulo de correlación de acontecimientos (802), el módulo de depósitos de insulina (848) y el módulo de anulación de insulina (836), y en el que el módulo de inicialización/preparación (800) es el vector de estado del controlador ALGO (510) que gestiona la información pasada, actual y futura, el módulo de manejo de ciclo perdido (801) maneja el reinicio de las llamadas que se omitieron por cualquier motivo, el módulo de correlación de acontecimientos (802) correlaciona el conjunto de acontecimientos externos con el conjunto de acontecimientos internos, el módulo de depósitos de insulina (848) gestiona la recomendación de insulina de diversos módulos como componentes para llenar y vaciar depósitos, y el módulo de anulación de insulina (836) invalida cualquier componente de insulina que proceda de los términos de prealimentación de una acción de control de una administración de insulina final.
9. El sistema (10) de acuerdo con una cualquiera de las reivindicaciones precedentes, en el que el módulo EA (518) comprende además módulos para supervisar e informar del estado que incluyen el módulo de actualización de glucosa (808) que hace un seguimiento de la disponibilidad de nuevos valores de medición de glucosa, y el módulo de glucosa desactualizado (814) que informa al paciente si es necesario un valor de glucosa reciente, y que además incluyen un módulo de inyección intravenosa rápida automática (810) que tiene en cuenta cualquier discrepancia de insulina por medio de órdenes de inyección intravenosa rápida automática, y un módulo de aviso de comidas (842) que informa al paciente para que comience a comer.
10. El sistema (10) de acuerdo con una cualquiera de las reivindicaciones precedentes, en el que el módulo EA (518) comprende además módulos para acciones correctivas que incluyen un módulo de rectificación de carbohidratos (834), un módulo de intervención de alto contenido de glucosa (832), un módulo de intervención de bajo contenido de glucosa (826), un módulo de zona de glucosa de comidas (820) y un módulo de gestión de discrepancias (818), y en el que el módulo de 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, el módulo de intervención de alto contenido de glucosa (832) corrige el nivel alto de glucosa por medio de la administración de insulina, el módulo de intervención de bajo contenido de glucosa (826) corrige el nivel bajo de glucosa por medio de la recomendación de la ingesta de carbohidratos de acción rápida, el módulo de la zona de glucosa de comidas (820) define el objetivo de glucosa como una zona que tiene un intervalo de puntos fijos inferiores y superiores, y el módulo de gestión de discrepancias (818) gestiona los depósitos de insulina cuando se identifica la discrepancia entre la insulina ordenada frente a la insulina administrada.
11. El sistema (10) de acuerdo con una cualquiera de las reivindicaciones precedentes, en el que el módulo EA (518) comprende además módulos para manejar acontecimientos importantes que incluyen un módulo de preparación para ejercicio (828) y un módulo de inyección intravenosa rápida ordenada (830), y en el que el módulo de preparación para ejercicio (828) revisa el requisito basal en anticipación al controlador de ejercicio e informa al controlador (510) al inicio de un ejercicio específico, y la solicitud del módulo de inyección intravenosa rápida ordenada (830) de una inyección intravenosa rápida de insulina adicional.
12. El sistema (10) de acuerdo con una cualquiera de las reivindicaciones precedentes, en el que se proporciona tiempo simulado al controlador ALGO (510) de modo que se proporciona un entorno simulado.
13. El sistema (10) de acuerdo con una cualquiera de las reivindicaciones precedentes, que comprende además una interfaz de usuario (900) que permite la introducción de datos de un usuario para configurar y ejecutar una simulación que usa el módulo EA (518) y el controlador ALGO (510) en un entorno simulado para desarrollar tratamientos específicos del paciente.
ES12002462T 2007-06-27 2008-05-12 Sistema para determinar una administración de insulina y comunicar una dosis en un programa informático de páncreas automatizado Active ES2845400T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US94661507P 2007-06-27 2007-06-27

Publications (1)

Publication Number Publication Date
ES2845400T3 true ES2845400T3 (es) 2021-07-26

Family

ID=39682584

Family Applications (1)

Application Number Title Priority Date Filing Date
ES12002462T Active ES2845400T3 (es) 2007-06-27 2008-05-12 Sistema para determinar una administración de insulina y comunicar una dosis en un programa informático de páncreas automatizado

Country Status (9)

Country Link
US (1) US8818782B2 (es)
EP (2) EP2562664B1 (es)
JP (2) JP5209714B2 (es)
KR (2) KR101423807B1 (es)
CN (1) CN101689224B (es)
CA (1) CA2687562C (es)
DK (1) DK2562664T3 (es)
ES (1) ES2845400T3 (es)
WO (1) WO2009002620A1 (es)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200168313A1 (en) * 2017-07-28 2020-05-28 W.O.M. World Of Medicine Gmbh Medical engineering apparatus for storing and evaluating clinical data
WO2023135346A1 (es) 2022-01-12 2023-07-20 Universidad Complutense De Madrid Método y sistema para predicción de valores de glucosa y generación de alertas de hipoglucemia e hiperglucemia

Families Citing this family (369)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190357827A1 (en) 2003-08-01 2019-11-28 Dexcom, Inc. Analyte sensor
US8065161B2 (en) 2003-11-13 2011-11-22 Hospira, Inc. System for maintaining drug information and communicating with medication delivery devices
US9123077B2 (en) 2003-10-07 2015-09-01 Hospira, Inc. Medication management system
US7697967B2 (en) 2005-12-28 2010-04-13 Abbott Diabetes Care Inc. Method and apparatus for providing analyte sensor insertion
US9788771B2 (en) 2006-10-23 2017-10-17 Abbott Diabetes Care Inc. Variable speed sensor insertion devices and methods of use
US7785258B2 (en) 2005-10-06 2010-08-31 Optiscan Biomedical Corporation System and method for determining a treatment dose for a patient
US8251907B2 (en) * 2005-02-14 2012-08-28 Optiscan Biomedical Corporation System and method for determining a treatment dose for a patient
CA2620586A1 (en) 2005-08-31 2007-03-08 Boris P. Kovatchev Improving the accuracy of continuous glucose sensors
US8543420B2 (en) 2007-09-19 2013-09-24 Fresenius Medical Care Holdings, Inc. Patient-specific content delivery methods and systems
US11298058B2 (en) 2005-12-28 2022-04-12 Abbott Diabetes Care Inc. Method and apparatus for providing analyte sensor insertion
US7736310B2 (en) 2006-01-30 2010-06-15 Abbott Diabetes Care Inc. On-body medical device securement
US7885698B2 (en) 2006-02-28 2011-02-08 Abbott Diabetes Care Inc. Method and system for providing continuous calibration of implantable analyte sensors
US7618369B2 (en) 2006-10-02 2009-11-17 Abbott Diabetes Care Inc. Method and system for dynamically updating calibration parameters for an analyte sensor
US9392969B2 (en) 2008-08-31 2016-07-19 Abbott Diabetes Care Inc. Closed loop control and signal attenuation detection
US8346335B2 (en) 2008-03-28 2013-01-01 Abbott Diabetes Care Inc. Analyte sensor calibration management
US7630748B2 (en) 2006-10-25 2009-12-08 Abbott Diabetes Care Inc. Method and system for providing analyte monitoring
US9675290B2 (en) 2012-10-30 2017-06-13 Abbott Diabetes Care Inc. Sensitivity calibration of in vivo sensors used to measure analyte concentration
US8219173B2 (en) 2008-09-30 2012-07-10 Abbott Diabetes Care Inc. Optimizing analyte sensor calibration
US8224415B2 (en) 2009-01-29 2012-07-17 Abbott Diabetes Care Inc. Method and device for providing offset model based calibration for analyte sensor
US8374668B1 (en) 2007-10-23 2013-02-12 Abbott Diabetes Care Inc. Analyte sensor with lag compensation
US8140312B2 (en) 2007-05-14 2012-03-20 Abbott Diabetes Care Inc. Method and system for determining analyte levels
US8473022B2 (en) 2008-01-31 2013-06-25 Abbott Diabetes Care Inc. Analyte sensor with time lag compensation
US7653425B2 (en) 2006-08-09 2010-01-26 Abbott Diabetes Care Inc. Method and system for providing calibration of an analyte sensor in an analyte monitoring system
WO2008057729A2 (en) 2006-10-16 2008-05-15 Hospira, Inc. System and method for comparing and utilizing activity information and configuration information from mulitple device management systems
AU2007308804A1 (en) 2006-10-26 2008-05-02 Abbott Diabetes Care, Inc. Method, system and computer program product for real-time detection of sensitivity decline in analyte sensors
US8930203B2 (en) 2007-02-18 2015-01-06 Abbott Diabetes Care Inc. Multi-function analyte test device and methods therefor
US8732188B2 (en) 2007-02-18 2014-05-20 Abbott Diabetes Care Inc. Method and system for providing contextual based medication dosage determination
ES2461090T3 (es) 2007-04-14 2014-05-16 Abbott Diabetes Care Inc. Procedimiento y aparato para proporcionar tratamiento y control de datos en un sistema de comunicación médica
WO2008130898A1 (en) * 2007-04-14 2008-10-30 Abbott Diabetes Care, Inc. Method and apparatus for providing data processing and control in medical communication system
CA2683959C (en) 2007-04-14 2017-08-29 Abbott Diabetes Care Inc. Method and apparatus for providing data processing and control in medical communication system
WO2009096992A1 (en) 2007-04-14 2009-08-06 Abbott Diabetes Care, Inc. Method and apparatus for providing data processing and control in medical communication system
US10002233B2 (en) 2007-05-14 2018-06-19 Abbott Diabetes Care Inc. Method and apparatus for providing data processing and control in a medical communication system
US8260558B2 (en) 2007-05-14 2012-09-04 Abbott Diabetes Care Inc. Method and apparatus for providing data processing and control in a medical communication system
US8444560B2 (en) 2007-05-14 2013-05-21 Abbott Diabetes Care Inc. Method and apparatus for providing data processing and control in a medical communication system
US8560038B2 (en) 2007-05-14 2013-10-15 Abbott Diabetes Care Inc. Method and apparatus for providing data processing and control in a medical communication system
US8600681B2 (en) 2007-05-14 2013-12-03 Abbott Diabetes Care Inc. Method and apparatus for providing data processing and control in a medical communication system
US8239166B2 (en) 2007-05-14 2012-08-07 Abbott Diabetes Care Inc. Method and apparatus for providing data processing and control in a medical communication system
US8103471B2 (en) 2007-05-14 2012-01-24 Abbott Diabetes Care Inc. Method and apparatus for providing data processing and control in a medical communication system
US9125548B2 (en) 2007-05-14 2015-09-08 Abbott Diabetes Care Inc. Method and apparatus for providing data processing and control in a medical communication system
US8417311B2 (en) * 2008-09-12 2013-04-09 Optiscan Biomedical Corporation Fluid component analysis system and method for glucose monitoring and control
US7751907B2 (en) 2007-05-24 2010-07-06 Smiths Medical Asd, Inc. Expert system for insulin pump therapy
US8221345B2 (en) 2007-05-30 2012-07-17 Smiths Medical Asd, Inc. Insulin pump based expert system
US8160900B2 (en) 2007-06-29 2012-04-17 Abbott Diabetes Care Inc. Analyte monitoring and management device and method to analyze the frequency of user interaction with the device
US8834366B2 (en) 2007-07-31 2014-09-16 Abbott Diabetes Care Inc. Method and apparatus for providing analyte sensor calibration
US20090063402A1 (en) * 2007-08-31 2009-03-05 Abbott Diabetes Care, Inc. Method and System for Providing Medication Level Determination
CA2702116C (en) 2007-10-10 2021-01-05 Optiscan Biomedical Corporation Fluid component analysis system and method for glucose monitoring and control
US8377031B2 (en) * 2007-10-23 2013-02-19 Abbott Diabetes Care Inc. Closed loop control system with safety parameters and methods
US8409093B2 (en) 2007-10-23 2013-04-02 Abbott Diabetes Care Inc. Assessing measures of glycemic variability
US8517990B2 (en) 2007-12-18 2013-08-27 Hospira, Inc. User interface improvements for medical devices
US20090164239A1 (en) 2007-12-19 2009-06-25 Abbott Diabetes Care, Inc. Dynamic Display Of Glucose Information
US20090177142A1 (en) 2008-01-09 2009-07-09 Smiths Medical Md, Inc Insulin pump with add-on modules
US20100145725A1 (en) * 2008-02-12 2010-06-10 Alferness Clifton A System and method for managing type 1 diabetes mellitus through a personal predictive management tool
US20100145174A1 (en) * 2008-02-12 2010-06-10 Alferness Clifton A System And Method For Providing A Personalized Tool For Estimating Glycated Hemoglobin
US20100145173A1 (en) * 2008-02-12 2010-06-10 Alferness Clifton A System and method for creating a personalized tool predicting a time course of blood glucose affect in diabetes mellitus
US20100137786A1 (en) * 2008-02-12 2010-06-03 Alferness Clifton A System and method for actively managing type 1 diabetes mellitus on a personalized basis
US20100138453A1 (en) * 2008-02-12 2010-06-03 Alferness Clifton A System and method for generating a personalized diabetes management tool for diabetes mellitus
US20100198020A1 (en) * 2008-02-12 2010-08-05 Alferness Clifton A System And Method For Computer-Implemented Method For Actively Managing Increased Insulin Resistance In Type 2 Diabetes Mellitus
US20110077930A1 (en) * 2008-02-12 2011-03-31 Alferness Clifton A Computer-implemented method for providing a personalized tool for estimating 1,5-anhydroglucitol
US20100138203A1 (en) * 2008-02-12 2010-06-03 Alferness Clifton A System and method for actively managing type 2 diabetes mellitus on a personalized basis
US20100198021A1 (en) * 2008-02-12 2010-08-05 Alferness Clifton A Computer-implemented method for providing a tunable personalized tool for estimating glycated hemoglobin
US20100145670A1 (en) * 2008-02-12 2010-06-10 Alferness Clifton A System and method for managing type 2 diabetes mellitus through a personal predictive management tool
US8591410B2 (en) 2008-05-30 2013-11-26 Abbott Diabetes Care Inc. Method and apparatus for providing glycemic control
US8924159B2 (en) 2008-05-30 2014-12-30 Abbott Diabetes Care Inc. Method and apparatus for providing glycemic control
US8126228B2 (en) * 2008-06-18 2012-02-28 International Business Machines Corporation Determining efficacy of therapeutic intervention in neurosychiatric disease
US8199982B2 (en) * 2008-06-18 2012-06-12 International Business Machines Corporation Mapping of literature onto regions of interest on neurological images
US20090320092A1 (en) * 2008-06-24 2009-12-24 Microsoft Corporation User interface for managing access to a health-record
US8548823B2 (en) * 2008-07-08 2013-10-01 International Business Machines Corporation Automatically determining ideal treatment plans for complex neuropsychiatric conditions
US9198612B2 (en) 2008-07-08 2015-12-01 International Business Machines Corporation Determination of neuropsychiatric therapy mechanisms of action
US8168063B2 (en) * 2008-07-09 2012-05-01 Baxter International Inc. Dialysis system having filtering method for determining therapy prescriptions
US8057679B2 (en) * 2008-07-09 2011-11-15 Baxter International Inc. Dialysis system having trending and alert generation
US8062513B2 (en) * 2008-07-09 2011-11-22 Baxter International Inc. Dialysis system and machine having therapy prescription recall
US8876755B2 (en) * 2008-07-14 2014-11-04 Abbott Diabetes Care Inc. Closed loop control system interface and methods
US7959598B2 (en) 2008-08-20 2011-06-14 Asante Solutions, Inc. Infusion pump systems and methods
US20100057040A1 (en) 2008-08-31 2010-03-04 Abbott Diabetes Care, Inc. Robust Closed Loop Control And Methods
US9943644B2 (en) * 2008-08-31 2018-04-17 Abbott Diabetes Care Inc. Closed loop control with reference measurement and methods thereof
WO2010031059A2 (en) 2008-09-15 2010-03-18 Deka Products Limited Partnership Systems and methods for fluid delivery
US8986208B2 (en) 2008-09-30 2015-03-24 Abbott Diabetes Care Inc. Analyte sensor sensitivity attenuation mitigation
US9326707B2 (en) 2008-11-10 2016-05-03 Abbott Diabetes Care Inc. Alarm characterization for analyte monitoring devices and systems
US8849458B2 (en) 2008-12-23 2014-09-30 Roche Diagnostics Operations, Inc. Collection device with selective display of test results, method and computer program product thereof
US9117015B2 (en) 2008-12-23 2015-08-25 Roche Diagnostics Operations, Inc. Management method and system for implementation, execution, data collection, and data analysis of a structured collection procedure which runs on a collection device
US10456036B2 (en) 2008-12-23 2019-10-29 Roche Diabetes Care, Inc. Structured tailoring
KR20110097889A (ko) 2008-12-23 2011-08-31 에프. 호프만-라 로슈 아게 수집 디바이스 상에서 구동하는 구조화된 수집 절차의 구현, 실행, 데이터 수집, 및 데이터 분석을 위한 관리 방법 및 시스템
US9918635B2 (en) 2008-12-23 2018-03-20 Roche Diabetes Care, Inc. Systems and methods for optimizing insulin dosage
US10437962B2 (en) * 2008-12-23 2019-10-08 Roche Diabetes Care Inc Status reporting of a structured collection procedure
US20120011125A1 (en) 2008-12-23 2012-01-12 Roche Diagnostics Operations, Inc. Management method and system for implementation, execution, data collection, and data analysis of a structured collection procedure which runs on a collection device
US8698741B1 (en) 2009-01-16 2014-04-15 Fresenius Medical Care Holdings, Inc. Methods and apparatus for medical device cursor control and touchpad-based navigation
US20140363794A1 (en) * 2009-01-26 2014-12-11 EosHealth, Inc. Diabetic Patients Compliance and Outcomes by Publicizing that Increased Compliance Improves Blood Glucose Control and Outcomes
US8103456B2 (en) 2009-01-29 2012-01-24 Abbott Diabetes Care Inc. Method and device for early signal attenuation detection using blood glucose measurements
US20100198196A1 (en) * 2009-01-30 2010-08-05 Abbott Diabetes Care, Inc. Therapy Delivery Device Programming Tool
US9402544B2 (en) 2009-02-03 2016-08-02 Abbott Diabetes Care Inc. Analyte sensor and apparatus for insertion of the sensor
WO2010091102A1 (en) * 2009-02-04 2010-08-12 Abbott Diabetes Care Inc. Multi-function analyte test device and methods therefor
US8497777B2 (en) 2009-04-15 2013-07-30 Abbott Diabetes Care Inc. Analyte monitoring system having an alert
US8271106B2 (en) 2009-04-17 2012-09-18 Hospira, Inc. System and method for configuring a rule set for medical event management and responses
US8483967B2 (en) 2009-04-29 2013-07-09 Abbott Diabetes Care Inc. Method and system for providing real time analyte sensor calibration with retrospective backfill
US8597274B2 (en) 2009-05-22 2013-12-03 Abbott Diabetes Care Inc. Usability features for integrated insulin delivery system
EP2435962B1 (en) * 2009-05-29 2023-04-19 University of Virginia Patent Foundation System coordinator and modular architecture for open-loop and closed-loop control of diabetes
US20100324932A1 (en) * 2009-06-19 2010-12-23 Roche Diagnostics Operations, Inc. Methods and systems for advising people with diabetes
US20110196213A1 (en) * 2009-06-26 2011-08-11 Roche Diagnostics Operations, Inc. Display For Biological Values
EP3689237B1 (en) 2009-07-23 2021-05-19 Abbott Diabetes Care, Inc. Method of manufacturing and system for continuous analyte measurement
DK3173014T4 (da) * 2009-07-23 2026-03-30 Abbott Diabetes Care Inc Realtidsstyring af data vedrørende fysiologisk kontrol af glucoseniveauer
EP4070727B1 (en) 2009-08-31 2023-07-05 Abbott Diabetes Care, Inc. Displays for a medical device
WO2011028731A1 (en) * 2009-09-01 2011-03-10 University Of Virginia Patent Foundation System, method and computer program product for adjustment of insulin delivery (aid) in diabetes using nominal open-loop profiles
KR101632308B1 (ko) * 2009-09-23 2016-06-21 삼성전자주식회사 혈당 관리 정보를 제공하는 방법 및 장치
US9320461B2 (en) 2009-09-29 2016-04-26 Abbott Diabetes Care Inc. Method and apparatus for providing notification function in analyte monitoring systems
JP5728767B2 (ja) * 2009-09-30 2015-06-03 ドリームド・ダイアベティス・リミテッド インスリン送達の管理のための監視システム、方法、およびコンピュータプログラム
WO2011053881A1 (en) 2009-10-30 2011-05-05 Abbott Diabetes Care Inc. Method and apparatus for detecting false hypoglycemic conditions
US8632485B2 (en) 2009-11-05 2014-01-21 Fresenius Medical Care Holdings, Inc. Patient treatment and monitoring systems and methods
US10799117B2 (en) 2009-11-05 2020-10-13 Fresenius Medical Care Holdings, Inc. Patient treatment and monitoring systems and methods with cause inferencing
US8771251B2 (en) 2009-12-17 2014-07-08 Hospira, Inc. Systems and methods for managing and delivering patient therapy through electronic drug delivery systems
US20110208027A1 (en) * 2010-02-23 2011-08-25 Roche Diagnostics Operations, Inc. Methods And Systems For Providing Therapeutic Guidelines To A Person Having Diabetes
US20110237918A1 (en) * 2010-02-23 2011-09-29 Robin Wagner Methods and systems for providing therapeutic guidelines to a person having diabetes
WO2011112753A1 (en) 2010-03-10 2011-09-15 Abbott Diabetes Care Inc. Systems, devices and methods for managing glucose levels
US20110230731A1 (en) * 2010-03-22 2011-09-22 General Electric Company Method, device and computer program product for determining an indicator of general clinical state
ES2881798T3 (es) 2010-03-24 2021-11-30 Abbott Diabetes Care Inc Insertadores de dispositivos médicos y procedimientos de inserción y uso de dispositivos médicos
US8532933B2 (en) 2010-06-18 2013-09-10 Roche Diagnostics Operations, Inc. Insulin optimization systems and testing methods with adjusted exit criterion accounting for system noise associated with biomarkers
US8635046B2 (en) 2010-06-23 2014-01-21 Abbott Diabetes Care Inc. Method and system for evaluating analyte sensor response characteristics
US8543354B2 (en) * 2010-06-23 2013-09-24 Medtronic Minimed, Inc. Glucose sensor signal stability analysis
US10092229B2 (en) 2010-06-29 2018-10-09 Abbott Diabetes Care Inc. Calibration of analyte measurement system
JP5838557B2 (ja) 2010-07-05 2016-01-06 ソニー株式会社 生体情報処理方法および装置、並びに記録媒体
CN103003819A (zh) * 2010-07-23 2013-03-27 霍夫曼-拉罗奇有限公司 考虑到身体活动对葡萄糖调节系统的影响的系统和方法
US20120064006A1 (en) * 2010-08-06 2012-03-15 Jay Yadav Systems and methods for using physiological information
US20120053437A1 (en) * 2010-08-25 2012-03-01 Hickle Randall S Monitored healthcare process for the treatment of specific health problems with medical foods and/or drugs
US8707392B2 (en) * 2010-10-15 2014-04-22 Roche Diagnostics Operations, Inc. Systems and methods for disease management
ES2755497T3 (es) 2010-10-31 2020-04-22 Univ Boston Sistema de control de glucosa en sangre
GB201020086D0 (en) * 2010-11-26 2011-01-12 Hypo Safe As Analysis of EEG signals to detect hypoglycaemia
US10136845B2 (en) 2011-02-28 2018-11-27 Abbott Diabetes Care Inc. Devices, systems, and methods associated with analyte monitoring devices and devices incorporating the same
US9262719B2 (en) 2011-03-22 2016-02-16 Patrick Soon-Shiong Reasoning engines
EP3575796B1 (en) 2011-04-15 2020-11-11 DexCom, Inc. Advanced analyte sensor calibration and error detection
EP2700049A4 (en) * 2011-04-20 2015-08-19 Cleveland Clinic Foundation PREDICTIVE MODELING
US8755938B2 (en) * 2011-05-13 2014-06-17 Roche Diagnostics Operations, Inc. Systems and methods for handling unacceptable values in structured collection protocols
US8766803B2 (en) * 2011-05-13 2014-07-01 Roche Diagnostics Operations, Inc. Dynamic data collection
EP4122384A1 (en) 2011-06-16 2023-01-25 Abbott Diabetes Care, Inc. Temperature-compensated analyte monitoring devices, systems, and methods thereof
JP6067008B2 (ja) * 2011-06-30 2017-01-25 ユニヴァーシティ オヴ ピッツバーグ オヴ ザ コモンウェルス システム オヴ ハイアー エデュケーション 心肺機能不全に対する易罹患性（ｓｕｓｃｅｐｔｉｂｉｌｉｔｙ）を判断するシステム及び方法
CA2844807C (en) 2011-08-19 2022-07-26 Hospira, Inc. Systems and methods for a graphical interface including a graphical representation of medical data
EP2748747B1 (en) * 2011-08-26 2020-08-26 University Of Virginia Patent Foundation Method, system and computer readable medium for adaptive advisory control of diabetes
WO2013032845A1 (en) * 2011-08-26 2013-03-07 Wellpoint, Inc. System and method for creating and using health data record
EP4060673A1 (en) 2011-09-28 2022-09-21 Abbott Diabetes Care, Inc. Methods, devices and systems for analyte monitoring management
AU2012325937B2 (en) 2011-10-21 2018-03-01 Icu Medical, Inc. Medical device update system
US9622691B2 (en) 2011-10-31 2017-04-18 Abbott Diabetes Care Inc. Model based variable risk false glucose threshold alarm prevention mechanism
US9317656B2 (en) 2011-11-23 2016-04-19 Abbott Diabetes Care Inc. Compatibility mechanisms for devices in a continuous analyte monitoring system and methods thereof
US8710993B2 (en) 2011-11-23 2014-04-29 Abbott Diabetes Care Inc. Mitigating single point failure of devices in an analyte monitoring system and methods thereof
WO2013078426A2 (en) 2011-11-25 2013-05-30 Abbott Diabetes Care Inc. Analyte monitoring system and methods of use
AU2012352560B2 (en) 2011-12-11 2017-01-19 Abbott Diabetes Care Inc. Analyte sensor devices, connections, and methods
WO2013090709A1 (en) 2011-12-16 2013-06-20 Hospira, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
TW201333870A (zh) 2011-12-21 2013-08-16 艾登工具股份有限公司 決定病人胰島素療法的系統及方法
US9136939B2 (en) 2011-12-29 2015-09-15 Roche Diabetes Care, Inc. Graphical user interface pertaining to a bolus calculator residing on a handheld diabetes management device
JP5694206B2 (ja) * 2012-01-11 2015-04-01 日本電信電話株式会社 運動管理装置、運動管理方法及びプログラム
JP6306566B2 (ja) 2012-03-30 2018-04-04 アイシーユー・メディカル・インコーポレーテッド 注入システムのポンプ内の空気を検出するための空気検出システムおよび方法
US9238100B2 (en) 2012-06-07 2016-01-19 Tandem Diabetes Care, Inc. Device and method for training users of ambulatory medical devices
US8744828B2 (en) 2012-07-26 2014-06-03 Rimidi Diabetes, Inc. Computer-implemented system and method for improving glucose management through modeling of circadian profiles
US8768673B2 (en) 2012-07-26 2014-07-01 Rimidi Diabetes, Inc. Computer-implemented system and method for improving glucose management through cloud-based modeling of circadian profiles
US8756043B2 (en) 2012-07-26 2014-06-17 Rimidi Diabetes, Inc. Blood glucose meter and computer-implemented method for improving glucose management through modeling of circadian profiles
EP3586891B1 (en) 2012-07-31 2025-04-09 ICU Medical, Inc. Patient care system for critical medications
WO2014022711A1 (en) * 2012-08-01 2014-02-06 Yofimeter, Llc User interface for analyte monitoring systems
US10132793B2 (en) 2012-08-30 2018-11-20 Abbott Diabetes Care Inc. Dropout detection in continuous analyte monitoring data during data excursions
US9897565B1 (en) * 2012-09-11 2018-02-20 Aseko, Inc. System and method for optimizing insulin dosages for diabetic subjects
EP2901153A4 (en) 2012-09-26 2016-04-27 Abbott Diabetes Care Inc METHOD AND DEVICE FOR IMPROVING DELAY CORRECTION FUNCTION DURING IN VIVO MEASUREMENT OF ANALYZ CONCENTRATION WITH ANALYZ CONCENTRATION VARIABILITY AND RANGE DATA
KR101993716B1 (ko) 2012-09-28 2019-06-27 삼성전자주식회사 카테고리별 진단 모델을 이용한 병변 진단 장치 및 방법
SG10201907682RA (en) 2012-10-05 2019-10-30 Mould Diane System and method for providing patient-specific dosing as a function of mathematical models
US10085562B1 (en) 2016-10-17 2018-10-02 Steelcase Inc. Ergonomic seating system, tilt-lock control and remote powering method and appartus
US10038952B2 (en) 2014-02-04 2018-07-31 Steelcase Inc. Sound management systems for improving workplace efficiency
US12376677B1 (en) 2012-10-10 2025-08-05 Steelcase Inc. Ergonomic seating system, tilt-lock control and remote powering method and apparatus
US9486070B2 (en) 2012-10-10 2016-11-08 Stirworks Inc. Height-adjustable support surface and system for encouraging human movement and promoting wellness
US10827829B1 (en) 2012-10-10 2020-11-10 Steelcase Inc. Height adjustable support surface and system for encouraging human movement and promoting wellness
EP2922465A4 (en) 2012-11-21 2016-07-06 Cardiomems Inc DEVICES, SYSTEMS AND METHODS FOR ASSESSING AND TREATING PULMONARY ARTERIAL HYPERTENSION (PAH)
JP5511033B1 (ja) 2012-12-04 2014-06-04 Ｎｅｃシステムテクノロジー株式会社 血糖値予測装置、測定装置、血糖値予測方法、及びプログラム
WO2014116276A1 (en) * 2013-01-24 2014-07-31 Kantrack Llc Individualized medicine system
AU2014225658B2 (en) 2013-03-06 2018-05-31 Icu Medical, Inc. Medical device communication method
US20140257829A1 (en) * 2013-03-08 2014-09-11 Archimedes, Inc. Interactive healthcare modeling
US10357606B2 (en) 2013-03-13 2019-07-23 Tandem Diabetes Care, Inc. System and method for integration of insulin pumps and continuous glucose monitoring
US9474475B1 (en) 2013-03-15 2016-10-25 Abbott Diabetes Care Inc. Multi-rate analyte sensor data collection with sample rate configurable signal processing
US9242043B2 (en) 2013-03-15 2016-01-26 Tandem Diabetes Care, Inc. Field update of an ambulatory infusion pump system
WO2014145705A2 (en) 2013-03-15 2014-09-18 Battelle Memorial Institute Progression analytics system
US10076285B2 (en) 2013-03-15 2018-09-18 Abbott Diabetes Care Inc. Sensor fault detection using analyte sensor data pattern comparison
US10433773B1 (en) 2013-03-15 2019-10-08 Abbott Diabetes Care Inc. Noise rejection methods and apparatus for sparsely sampled analyte sensor data
US9198908B2 (en) 2013-03-15 2015-12-01 St. Jude Medical Luxembourg Holdings Ii S.A.R.L. (“Sjm Lux Ii”) Methods for the treatment of cardiovascular conditions
AU2014268355B2 (en) 2013-05-24 2018-06-14 Icu Medical, Inc. Multi-sensor infusion system for detecting air or an occlusion in the infusion system
ES2845748T3 (es) 2013-05-29 2021-07-27 Icu Medical Inc Sistema de infusión y método de uso que impiden la sobresaturación de un convertidor analógico-digital
CA2913915C (en) 2013-05-29 2022-03-29 Hospira, Inc. Infusion system which utilizes one or more sensors and additional information to make an air determination regarding the infusion system
US9561324B2 (en) 2013-07-19 2017-02-07 Bigfoot Biomedical, Inc. Infusion pump system and method
WO2015021041A2 (en) * 2013-08-05 2015-02-12 Hygieia, Inc. Systems, devices, and methods for alleviating glucotoxicity and restoring pancreatic beta-cell function in advanced diabetes mellitus
JP6621748B2 (ja) 2013-08-30 2019-12-18 アイシーユー・メディカル・インコーポレーテッド 遠隔輸液レジメンを監視および管理するシステムならびに方法
CN104426899B (zh) * 2013-09-11 2020-11-24 上海联影医疗科技有限公司 一种诊断协议集合的动态设置方法
US9662436B2 (en) 2013-09-20 2017-05-30 Icu Medical, Inc. Fail-safe drug infusion therapy system
US10311972B2 (en) 2013-11-11 2019-06-04 Icu Medical, Inc. Medical device system performance index
US10042986B2 (en) 2013-11-19 2018-08-07 Icu Medical, Inc. Infusion pump automation system and method
US20150149235A1 (en) * 2013-11-27 2015-05-28 General Electric Company Methods and systems to improve a quality of data employed by a healthcare analytics system
CN103705247A (zh) * 2013-12-09 2014-04-09 杨荣 具有血糖变化记录功能的血糖检测仪
AU2014374361B9 (en) 2013-12-31 2019-07-04 Abbott Diabetes Care Inc. Self-powered analyte sensor and devices using the same
JP6499668B2 (ja) 2014-01-28 2019-04-10 デビオテック ソシエテ アノニム 制御インターフェース、患者に対する流体の管理を制御するシステム、薬剤送給装置を制御する方法、処置システムを使用している患者の糖尿病を治療する装置、糖尿病の治療のための患者の学習方法、及びインスリンの量を推奨する方法
GB2523989B (en) 2014-01-30 2020-07-29 Insulet Netherlands B V Therapeutic product delivery system and method of pairing
EP3089667B1 (en) 2014-01-31 2022-04-13 Trustees of Boston University Offline glucose control based on preceding periods
WO2015131108A2 (en) 2014-02-28 2015-09-03 Hospira, Inc. Infusion system and method which utilizes dual wavelength optical air-in-line detection
US20170185748A1 (en) 2014-03-30 2017-06-29 Abbott Diabetes Care Inc. Method and Apparatus for Determining Meal Start and Peak Events in Analyte Monitoring Systems
JP2015194967A (ja) * 2014-03-31 2015-11-05 富士通株式会社 投薬量出力制御プログラム、投薬量出力制御方法および投薬量出力制御装置
US9764082B2 (en) 2014-04-30 2017-09-19 Icu Medical, Inc. Patient care system with conditional alarm forwarding
GB201407896D0 (en) * 2014-05-05 2014-06-18 Joanneum Res Forschungsgmbh Insulin dosage proposal system
US10007765B2 (en) * 2014-05-19 2018-06-26 Medtronic Minimed, Inc. Adaptive signal processing for infusion devices and related methods and systems
US11344673B2 (en) 2014-05-29 2022-05-31 Icu Medical, Inc. Infusion system and pump with configurable closed loop delivery rate catch-up
US9724470B2 (en) 2014-06-16 2017-08-08 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
US9539383B2 (en) 2014-09-15 2017-01-10 Hospira, Inc. System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein
GB201420436D0 (en) * 2014-11-18 2014-12-31 Ixico Ltd Device
US11344668B2 (en) 2014-12-19 2022-05-31 Icu Medical, Inc. Infusion system with concurrent TPN/insulin infusion
US20160188788A1 (en) * 2014-12-27 2016-06-30 John C. Weast Technologies for tuning a bio-chemical system
CN111905188B (zh) 2015-02-18 2022-07-22 英赛罗公司 流体输送和输注装置及其使用方法
US10850024B2 (en) 2015-03-02 2020-12-01 Icu Medical, Inc. Infusion system, device, and method having advanced infusion features
WO2016141481A1 (en) * 2015-03-09 2016-09-15 Mosca Michele Quantum circuit synthesis using deterministic walks
CN104834989A (zh) * 2015-03-27 2015-08-12 首都医科大学附属北京世纪坛医院 一种多病种慢性病信息管理系统
US10188809B2 (en) * 2015-04-03 2019-01-29 Zyno Medical, Llc Therapy-specific medical pump
CA2988724C (en) 2015-04-09 2023-10-10 Diane R. Mould Systems and methods for patient-specific dosing
EP3295341A1 (en) * 2015-05-08 2018-03-21 POPS! Diabetes Care, Inc. Blood glucose management system
CA2984939A1 (en) 2015-05-14 2016-11-17 Abbott Diabetes Care Inc. Compact medical device inserters and related systems and methods
EP3304370B1 (en) 2015-05-26 2020-12-30 ICU Medical, Inc. Infusion pump system and method with multiple drug library editor source capability
US11553883B2 (en) 2015-07-10 2023-01-17 Abbott Diabetes Care Inc. System, device and method of dynamic glucose profile response to physiological parameters
WO2017027459A1 (en) 2015-08-07 2017-02-16 Trustees Of Boston University Glucose control system with automatic adaptation of glucose target
WO2017031440A1 (en) * 2015-08-20 2017-02-23 Aseko, Inc. Diabetes management therapy advisor
JP6532355B2 (ja) * 2015-08-28 2019-06-19 キヤノン株式会社 画像形成装置
WO2017061943A1 (en) * 2015-10-09 2017-04-13 Dianovator Ab Medical arrangements and a method for determining parameters related to insulin therapy, predicting glucose values and for providing insulin dosing recommendations
WO2017123525A1 (en) 2016-01-13 2017-07-20 Bigfoot Biomedical, Inc. User interface for diabetes management system
US10806859B2 (en) 2016-01-14 2020-10-20 Bigfoot Biomedical, Inc. Adjusting insulin delivery rates
HK1256995A1 (zh) 2016-01-14 2019-10-11 Bigfoot Biomedical, Inc. 药物输送设备、系统和方法中的阻塞解决方案
US20170209103A1 (en) * 2016-01-25 2017-07-27 Lifeq Global Limited Simplified Instances of Virtual Physiological Systems for Internet of Things Processing
EP4303884A3 (en) 2016-01-29 2024-04-03 University of Virginia Patent Foundation d/b/a University of Virginia Licensing & Ventures Group Method, system, and computer readable medium for virtualization of a continuous glucose monitoring trace
US10541987B2 (en) 2016-02-26 2020-01-21 Tandem Diabetes Care, Inc. Web browser-based device communication workflow
CA3020346A1 (en) 2016-04-15 2017-10-19 Baxalta Incorporated Method and apparatus for providing a pharmacokinetic drug dosing regimen
CA3023658C (en) 2016-05-13 2023-03-07 Icu Medical, Inc. Infusion pump system and method with common line auto flush
US12383166B2 (en) 2016-05-23 2025-08-12 Insulet Corporation Insulin delivery system and methods with risk-based set points
US9921726B1 (en) 2016-06-03 2018-03-20 Steelcase Inc. Smart workstation method and system
US11062798B2 (en) * 2016-06-07 2021-07-13 Aseko, Inc. Managing insulin administration
AU2017277804B2 (en) 2016-06-10 2022-05-26 Icu Medical, Inc. Acoustic flow sensor for continuous medication flow measurements and feedback control of infusion
WO2018013842A1 (en) 2016-07-14 2018-01-18 Icu Medical, Inc. Multi-communication path selection and security system for a medical device
EP3504652B1 (en) * 2016-08-25 2024-02-28 Novo Nordisk A/S Starter kit for basal insulin titration
JP6629157B2 (ja) 2016-09-06 2020-01-15 株式会社東芝 システム
US10765807B2 (en) 2016-09-23 2020-09-08 Insulet Corporation Fluid delivery device with sensor
US10313422B2 (en) * 2016-10-17 2019-06-04 Hitachi, Ltd. Controlling a device based on log and sensor data
MA46993A (fr) 2016-11-29 2019-10-09 Novo Nordisk As Trousse de départ pour titrage de taux de base
US11096624B2 (en) 2016-12-12 2021-08-24 Bigfoot Biomedical, Inc. Alarms and alerts for medication delivery devices and systems
EP3568860B1 (en) 2017-01-13 2025-12-10 Insulet Corporation Insulin delivery methods, systems and devices
US11033682B2 (en) 2017-01-13 2021-06-15 Bigfoot Biomedical, Inc. Insulin delivery methods, systems and devices
US10881792B2 (en) 2017-01-13 2021-01-05 Bigfoot Biomedical, Inc. System and method for adjusting insulin delivery
US10758675B2 (en) 2017-01-13 2020-09-01 Bigfoot Biomedical, Inc. System and method for adjusting insulin delivery
US10583250B2 (en) 2017-01-13 2020-03-10 Bigfoot Biomedical, Inc. System and method for adjusting insulin delivery
US10500334B2 (en) 2017-01-13 2019-12-10 Bigfoot Biomedical, Inc. System and method for adjusting insulin delivery
US11071478B2 (en) 2017-01-23 2021-07-27 Abbott Diabetes Care Inc. Systems, devices and methods for analyte sensor insertion
US10896749B2 (en) 2017-01-27 2021-01-19 Shire Human Genetic Therapies, Inc. Drug monitoring tool
US11596330B2 (en) 2017-03-21 2023-03-07 Abbott Diabetes Care Inc. Methods, devices and system for providing diabetic condition diagnosis and therapy
EP3631805A4 (en) * 2017-06-02 2021-03-24 Mayo Foundation for Medical Education and Research SYSTEM AND METHOD FOR PROVIDING EXPERTISE FROM CLINICAL RESULTS IN DISEASE TREATMENT
WO2019055945A1 (en) * 2017-09-18 2019-03-21 Skellenger John Scott SYSTEM FOR RECOMMENDING A SERIES OF TREATMENTS
US12259933B2 (en) 2017-09-29 2025-03-25 Apple Inc. Techniques for anonymized searching of medical providers
US11587650B2 (en) * 2017-09-29 2023-02-21 Apple Inc. Techniques for managing access of user devices to third-party resources
US10824684B2 (en) 2017-09-29 2020-11-03 Apple Inc. Techniques for anonymized searching of medical providers
US11636927B2 (en) 2017-09-29 2023-04-25 Apple Inc. Techniques for building medical provider databases
US11822371B2 (en) 2017-09-29 2023-11-21 Apple Inc. Normalization of medical terms
US20200282142A1 (en) * 2017-10-19 2020-09-10 Sanofi Bolus Calculator and Method for Calculating a Bolus
US11331022B2 (en) 2017-10-24 2022-05-17 Dexcom, Inc. Pre-connected analyte sensors
US11382540B2 (en) 2017-10-24 2022-07-12 Dexcom, Inc. Pre-connected analyte sensors
US10426424B2 (en) 2017-11-21 2019-10-01 General Electric Company System and method for generating and performing imaging protocol simulations
JP7512203B2 (ja) * 2017-12-12 2024-07-08 ビッグフット バイオメディカル インコーポレイテッド 治療支援情報及び／又は追跡装置並びに関連する方法及びシステム
US10089055B1 (en) 2017-12-27 2018-10-02 Icu Medical, Inc. Synchronized display of screen content on networked devices
CN108428477A (zh) * 2018-03-30 2018-08-21 北京航空航天大学 基于数字双胞胎的云医疗仿真平台的构建方法及云医疗系统
USD928199S1 (en) 2018-04-02 2021-08-17 Bigfoot Biomedical, Inc. Medication delivery device with icons
FI3773798T3 (fi) * 2018-04-10 2024-08-16 Bigfoot Biomedical Inc Ajanhallinta aikaan sidottuihin hoidon hallintajärjestelmiin, menetelmiin ja laitteisiin
US11158413B2 (en) * 2018-04-23 2021-10-26 Medtronic Minimed, Inc. Personalized closed loop medication delivery system that utilizes a digital twin of the patient
US11147919B2 (en) 2018-04-23 2021-10-19 Medtronic Minimed, Inc. Methodology to recommend and implement adjustments to a fluid infusion device of a medication delivery system
US11565043B2 (en) * 2018-05-04 2023-01-31 Insulet Corporation Safety constraints for a control algorithm based drug delivery system
US12562251B1 (en) 2018-05-09 2026-02-24 Bigfoot Biomedical, Inc. Computing architecture for assuring the provenance of medication therapy related parameters, and related systems, methods and devices
KR102166670B1 (ko) * 2018-05-30 2020-10-16 경희대학교 산학협력단 사용자 건강 상태 제공 방법 및 장치
WO2019236850A1 (en) 2018-06-07 2019-12-12 Abbott Diabetes Care Inc. Focused sterilization and sterilized sub-assemblies for analyte monitoring systems
EP3824386B1 (en) 2018-07-17 2024-02-21 ICU Medical, Inc. Updating infusion pump drug libraries and operational software in a networked environment
NZ772135A (en) 2018-07-17 2022-11-25 Icu Medical Inc Systems and methods for facilitating clinical messaging in a network environment
US11139058B2 (en) 2018-07-17 2021-10-05 Icu Medical, Inc. Reducing file transfer between cloud environment and infusion pumps
US10950339B2 (en) 2018-07-17 2021-03-16 Icu Medical, Inc. Converting pump messages in new pump protocol to standardized dataset messages
AU2019309766B2 (en) 2018-07-26 2024-06-13 Icu Medical, Inc. Drug library management system
US10692595B2 (en) 2018-07-26 2020-06-23 Icu Medical, Inc. Drug library dynamic version management
US11547799B2 (en) * 2018-09-20 2023-01-10 Medtronic Minimed, Inc. Patient day planning systems and methods
AU2019347755B2 (en) 2018-09-28 2023-02-02 Insulet Corporation Activity mode for artificial pancreas system
US11139051B2 (en) 2018-10-02 2021-10-05 Origent Data Sciences, Inc. Systems and methods for designing clinical trials
WO2020074500A1 (en) * 2018-10-08 2020-04-16 F. Hoffmann-La Roche Ag Personalized treatment tool
US11224693B2 (en) 2018-10-10 2022-01-18 Tandem Diabetes Care, Inc. System and method for switching between medicament delivery control algorithms
EP3864668A1 (en) 2018-10-11 2021-08-18 Insulet Corporation Event detection for drug delivery system
MX2021007294A (es) 2018-12-21 2021-07-15 Abbott Diabetes Care Inc Sistemas, dispositivos y metodos para la insercion de sensores de analito.
US12233240B2 (en) 2018-12-26 2025-02-25 Tandem Diabetes Care, Inc. Methods of wireless communication in an infusion pump system
USD920343S1 (en) 2019-01-09 2021-05-25 Bigfoot Biomedical, Inc. Display screen or portion thereof with graphical user interface associated with insulin delivery
JP7270207B2 (ja) * 2019-01-10 2023-05-10 合同会社Ｈ．Ｕ．グループ中央研究所 情報処理方法、プログラムおよび情報処理装置
CN109754858B (zh) * 2019-01-11 2021-09-21 余鹏 甲氨蝶呤给药方案确定装置、存储介质及设备
KR102839034B1 (ko) * 2019-03-08 2025-07-28 다이앤 몰드 약물-불특정 환자별 투여 요법을 위한 시스템 및 방법
US11986629B2 (en) 2019-06-11 2024-05-21 Medtronic Minimed, Inc. Personalized closed loop optimization systems and methods
CN113826052B (zh) * 2019-04-25 2023-01-31 三菱电机株式会社 数据收集装置、数据收集方法及计算机可读取的非暂时性记录介质
EP3966992A4 (en) 2019-05-08 2023-06-21 ICU Medical, Inc. MEDICAL DEVICE MANAGEMENT BASED ON THRESHOLD DIGITAL SIGNATURES
US12138425B2 (en) 2019-05-21 2024-11-12 Tandem Diabetes Care, Inc. System and method for incorporating exercise into closed-loop diabetes therapy
US11657920B2 (en) 2019-07-08 2023-05-23 Koninklijke Philips N.V. Dynamic and locally-faithful explanation of machine learning models for precision medicine
US11957876B2 (en) 2019-07-16 2024-04-16 Beta Bionics, Inc. Glucose control system with automated backup therapy protocol generation
WO2021011697A1 (en) 2019-07-16 2021-01-21 Beta Bionics, Inc. Blood glucose control system
EP3998943A4 (en) 2019-07-16 2023-09-06 Beta Bionics, Inc. Blood glucose control system
US11553823B2 (en) * 2019-08-02 2023-01-17 International Business Machines Corporation Leveraging spatial scanning data of autonomous robotic devices
DE102019213000A1 (de) * 2019-08-29 2021-03-04 Siemens Healthcare Gmbh Durchführen von medizinischen Aufgaben basierend auf unvollständigen oder fehlerhaften Daten
US11801344B2 (en) 2019-09-13 2023-10-31 Insulet Corporation Blood glucose rate of change modulation of meal and correction insulin bolus quantity
US11935637B2 (en) * 2019-09-27 2024-03-19 Insulet Corporation Onboarding and total daily insulin adaptivity
CN114868200A (zh) * 2019-10-04 2022-08-05 贝塔仿生公司 血糖控制系统
US11654236B2 (en) 2019-11-22 2023-05-23 Tandem Diabetes Care, Inc. Systems and methods for automated insulin delivery for diabetes therapy
WO2021112748A1 (en) * 2019-12-03 2021-06-10 Mölnlycke Health Care Ab A method for determining a risk score for a patient
US11278671B2 (en) 2019-12-04 2022-03-22 Icu Medical, Inc. Infusion pump with safety sequence keypad
EP4069082B1 (en) 2019-12-06 2024-06-05 Insulet Corporation Techniques and devices providing adaptivity and personalization in diabetes treatment
US11833329B2 (en) 2019-12-20 2023-12-05 Insulet Corporation Techniques for improved automatic drug delivery performance using delivery tendencies from past delivery history and use patterns
JP7620633B2 (ja) * 2019-12-30 2025-01-23 エフ ホフマン－ラ ロッシュ アクチェン ゲゼルシャフト コンピュータで実現される糖尿病管理方法
JP7512395B2 (ja) 2020-01-06 2024-07-08 インスレット コーポレイション 持続する残差に基づく食事および／または運動行為の予測
EP4100958A1 (en) 2020-02-03 2022-12-14 Insulet Corporation Use of fuzzy logic in predicting user behavior affecting blood glucose concentration
US11551802B2 (en) 2020-02-11 2023-01-10 Insulet Corporation Early meal detection and calorie intake detection
US11986630B2 (en) 2020-02-12 2024-05-21 Insulet Corporation Dual hormone delivery system for reducing impending hypoglycemia and/or hyperglycemia risk
US11547800B2 (en) 2020-02-12 2023-01-10 Insulet Corporation User parameter dependent cost function for personalized reduction of hypoglycemia and/or hyperglycemia in a closed loop artificial pancreas system
US11324889B2 (en) * 2020-02-14 2022-05-10 Insulet Corporation Compensation for missing readings from a glucose monitor in an automated insulin delivery system
US12495994B2 (en) 2020-02-20 2025-12-16 Insulet Corporation Meal bolus subcategories in model based insulin therapy
USD1032624S1 (en) 2020-03-10 2024-06-25 Beta Bionics, Inc. Display screen with animated graphical user interface
US11278661B2 (en) 2020-03-10 2022-03-22 Beta Bionics, Inc. Infusion system and components thereof
WO2021183611A1 (en) * 2020-03-10 2021-09-16 Trustees Of Boston University Integrated user-defined input into a closed-loop glucose control system
US11590057B2 (en) 2020-04-03 2023-02-28 Icu Medical, Inc. Systems, methods, and components for transferring medical fluids
US11607493B2 (en) 2020-04-06 2023-03-21 Insulet Corporation Initial total daily insulin setting for user onboarding
CN112131096B (zh) * 2020-05-07 2024-05-24 北京国网信通埃森哲信息技术有限公司 Ict系统故障分析及辅助研判测试案例自动生成方法及装置
CN111403040A (zh) * 2020-06-04 2020-07-10 成都泰盟软件有限公司 基于虚拟标准病人的治疗模拟系统
WO2022006017A1 (en) 2020-07-02 2022-01-06 Icu Medical, Inc. Location-based reconfiguration of infusion pump settings
WO2022020277A1 (en) * 2020-07-19 2022-01-27 Jalli Inderpreet A system and method for developing an alternative drug therapy using characteristics of an existing drug therapy to produce a similar pathway behavior
AU2021311443A1 (en) 2020-07-21 2023-03-09 Icu Medical, Inc. Fluid transfer devices and methods of use
US12121700B2 (en) 2020-07-22 2024-10-22 Insulet Corporation Open-loop insulin delivery basal parameters based on insulin delivery records
US11684716B2 (en) 2020-07-31 2023-06-27 Insulet Corporation Techniques to reduce risk of occlusions in drug delivery systems
EP4203819B1 (en) 2020-08-31 2024-07-31 Abbott Diabetes Care Inc. Systems, devices, and methods for analyte sensor insertion
WO2022051230A1 (en) 2020-09-05 2022-03-10 Icu Medical, Inc. Identity-based secure medical device communications
US12576599B2 (en) 2020-09-15 2026-03-17 Abbott Diabetes Care Inc. Systems, devices, and methods for an analyte sensor
ES3000715T3 (en) 2020-09-15 2025-03-03 Abbott Diabetes Care Inc Device for analyte monitoring
US12569619B2 (en) 2020-09-21 2026-03-10 Insulet Corporation Techniques for determining automated insulin delivery dosages
KR102325887B1 (ko) * 2020-09-22 2021-11-15 큐어스트림(주) 혈당 조절 시스템 및 방법
US12115351B2 (en) 2020-09-30 2024-10-15 Insulet Corporation Secure wireless communications between a glucose monitor and other devices
EP4696344A3 (en) 2020-09-30 2026-04-15 Insulet Corporation Drug delivery device with integrated optical-based glucose monitor
CN112216178A (zh) * 2020-10-21 2021-01-12 北京高途云集教育科技有限公司 实验现象模拟方法、装置、系统和电子设备
US11594314B2 (en) 2020-12-07 2023-02-28 Beta Bionics, Inc. Modular blood glucose control systems
US20220208331A1 (en) * 2020-12-07 2022-06-30 Beta Bionics, Inc. Remote modification of therapy delivered by ambulatory medicament pump
US20220265143A1 (en) 2020-12-07 2022-08-25 Beta Bionics, Inc. Ambulatory medicament pumps with selective alarm muting
US20220199218A1 (en) 2020-12-07 2022-06-23 Beta Bionics, Inc. Ambulatory medicament pump with integrated medicament ordering interface
US11135360B1 (en) 2020-12-07 2021-10-05 Icu Medical, Inc. Concurrent infusion with common line auto flush
US11160925B1 (en) 2021-01-29 2021-11-02 Insulet Corporation Automatic drug delivery system for delivery of a GLP-1 therapeutic
US12364816B2 (en) 2021-02-19 2025-07-22 Medtronic Minimed, Inc. Glucose level management based on fat content of meals
US12329519B2 (en) * 2021-02-19 2025-06-17 Medtronic Minimed, Inc. Glucose level management based on protein content of meals
EP4305636A1 (en) 2021-03-10 2024-01-17 Insulet Corporation A medicament delivery device with an adjustable and piecewise analyte level cost component to address persistent positive analyte level excursions
US11904140B2 (en) 2021-03-10 2024-02-20 Insulet Corporation Adaptable asymmetric medicament cost component in a control system for medicament delivery
US12465686B2 (en) 2021-03-25 2025-11-11 Beta Bionics, Inc. Emergency medicament dose control
US12592306B2 (en) 2021-04-28 2026-03-31 Insulet Corporation Devices and methods for initialization of drug delivery devices using measured analyte sensor information
US11782771B2 (en) * 2021-05-20 2023-10-10 Vmware, Inc. Method and subsystem within a distributed log-analytics system that automatically determines and enforces log-retention periods for received log-event messages
US12496398B2 (en) 2021-05-28 2025-12-16 Insulet Corporation Threshold based automatic glucose control response
EP4101482A1 (en) 2021-06-07 2022-12-14 Insulet Corporation Exercise safety prediction based on physiological conditions
KR102571045B1 (ko) * 2021-06-21 2023-08-29 이오플로우(주) 최적의 인슐린 주입량을 산출하는 방법, 장치 및 컴퓨터 프로그램 제품
US12514980B2 (en) 2021-06-30 2026-01-06 Insulet Corporation Adjustment of medicament delivery by a medicament delivery device based on menstrual cycle phase
JP2024527596A (ja) 2021-07-16 2024-07-25 アボット ダイアベティス ケア インコーポレイテッド 検体監視のためのシステム、装置、及び方法
US12521486B2 (en) 2021-07-16 2026-01-13 Insulet Corporation Method for modification of insulin delivery during pregnancy in automatic insulin delivery systems
WO2023049900A1 (en) 2021-09-27 2023-03-30 Insulet Corporation Techniques enabling adaptation of parameters in aid systems by user input
US12599716B2 (en) 2021-10-12 2026-04-14 Icu Medical, Inc. Intravenous infusion pump with cassette insertion and pump control user interface
USD1091564S1 (en) 2021-10-13 2025-09-02 Icu Medical, Inc. Display screen or portion thereof with graphical user interface for a medical device
FR3129071B1 (fr) * 2021-11-18 2025-02-21 DiappyMed Dispositif de détermination dynamique de dose d’insuline basale à injecter
US11439754B1 (en) 2021-12-01 2022-09-13 Insulet Corporation Optimizing embedded formulations for drug delivery
CA3241894A1 (en) 2021-12-10 2023-06-15 Icu Medical, Inc. Medical fluid compounding systems with coordinated flow control
EP4207210A1 (en) * 2021-12-29 2023-07-05 Diabeloop Computerized method to assess confidence in a main predictive output determined by a predictive model
US20230268045A1 (en) * 2022-02-24 2023-08-24 Insight RX, Inc. Generation of analytics
EP4243030A1 (en) 2022-03-09 2023-09-13 Insulet Corporation Adjusting medicament delivery parameters in an open loop medicament delivery mode
US20230343430A1 (en) * 2022-04-21 2023-10-26 Insulet Corporation Medicament adaptation and safety monitoring
WO2023214777A1 (en) * 2022-05-02 2023-11-09 S-Alpha Therapeutics, Inc. Correlating health conditions with behaviors for treatment programs in neurohumoral behavioral therapy
WO2024026292A1 (en) * 2022-07-27 2024-02-01 Shiny New App, Llc Determining correlation strength of factors on symptom expression in health conditions using factor time
KR102869961B1 (ko) 2022-10-28 2025-10-13 가천대학교 산학협력단 팩터 모델을 이용한 헬스 케어 서비스 제공 방법 및 장치
EP4646726A1 (en) 2023-01-06 2025-11-12 Insulet Corporation Automatically or manually initiated meal bolus delivery with subsequent automatic safety constraint relaxation
US20250108160A1 (en) * 2023-09-28 2025-04-03 Tandem Diabetes Care, Inc. Systems and methods for managing messages sent to user of an insulin pump system
US20250356972A1 (en) * 2024-03-12 2025-11-20 Craig Alan Friedman Methods and systems that provide personalized medical treatments by deforming generic efficacy-estimation functions
WO2026059033A1 (ko) * 2024-09-12 2026-03-19 이오플로우㈜ 예측 혈당 기반 인슐린 주입량 조절 방법, 장치 및 프로그램

Family Cites Families (85)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4151845A (en) 1977-11-25 1979-05-01 Miles Laboratories, Inc. Blood glucose control apparatus
DD230730A3 (de) 1984-01-02 1985-12-11 Zentralinstitut Fuer Diabetes Einrichtung zur prospektiven automatischen bestimmung individualspezifischer glukoseregulationsparameter
US5193855A (en) 1989-01-25 1993-03-16 Shamos Morris H Patient and healthcare provider identification system
US20030212579A1 (en) 2002-05-08 2003-11-13 Brown Stephen J. Remote health management system
US5307263A (en) 1992-11-17 1994-04-26 Raya Systems, Inc. Modular microprocessor-based health monitoring system
US5899855A (en) 1992-11-17 1999-05-04 Health Hero Network, Inc. Modular microprocessor-based health monitoring system
US5956501A (en) 1997-01-10 1999-09-21 Health Hero Network, Inc. Disease simulation system and method
US5377258A (en) 1993-08-30 1994-12-27 National Medical Research Council Method and apparatus for an automated and interactive behavioral guidance system
US5660176A (en) 1993-12-29 1997-08-26 First Opinion Corporation Computerized medical diagnostic and treatment advice system
US5704366A (en) 1994-05-23 1998-01-06 Enact Health Management Systems System for monitoring and reporting medical measurements
US7574370B2 (en) 1994-10-28 2009-08-11 Cybear, L.L.C. Prescription management system
US5845255A (en) 1994-10-28 1998-12-01 Advanced Health Med-E-Systems Corporation Prescription management system
US7076436B1 (en) 1996-07-08 2006-07-11 Rlis, Inc. Medical records, documentation, tracking and order entry system
US5772585A (en) 1996-08-30 1998-06-30 Emc, Inc System and method for managing patient medical records
US6364834B1 (en) 1996-11-13 2002-04-02 Criticare Systems, Inc. Method and system for remotely monitoring multiple medical parameters in an integrated medical monitoring system
US6234964B1 (en) 1997-03-13 2001-05-22 First Opinion Corporation Disease management system and method
US6470320B1 (en) 1997-03-17 2002-10-22 The Board Of Regents Of The University Of Oklahoma Digital disease management system
US6558351B1 (en) 1999-06-03 2003-05-06 Medtronic Minimed, Inc. Closed loop system for controlling insulin infusion
WO1999023597A2 (en) 1997-10-31 1999-05-14 Amira Medical Analyte concentration information collection and communication s ystem
US6024699A (en) 1998-03-13 2000-02-15 Healthware Corporation Systems, methods and computer program products for monitoring, diagnosing and treating medical conditions of remotely located patients
US6525670B1 (en) 1998-10-23 2003-02-25 Matsushita Electric Works, Ltd. In-home health care system
US6149585A (en) 1998-10-28 2000-11-21 Sage Health Management Solutions, Inc. Diagnostic enhancement method and apparatus
AU1608300A (en) 1998-11-13 2000-06-05 George Edward Kriese Jr. System and method of storing medical records and providing information based upon a user's medical records
PL348630A1 (en) 1998-11-30 2002-06-03 Novo Nordisk As A method and a system for assisting a user in a medical self treatment, said self treatment comprising a plurality of actions
EP1146813A4 (en) 1998-12-01 2004-08-11 Health Hero Network Inc SYSTEM AND METHOD FOR IMPLEMENTING A PROCESSING SCHEME
JP2002531912A (ja) 1998-12-03 2002-09-24 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 積層組立体の形成方法
US20040028720A1 (en) 1998-12-29 2004-02-12 Remedy Marketing, Inc. Article for debridement & detoxification of wounds
WO2004112883A2 (en) 2003-06-20 2004-12-29 Metacure N.V. Hepatic device for treatment or glucose detection
EP1237463B1 (en) 1999-03-29 2008-05-14 Beckman Coulter, Inc. Meter with integrated database and simplified telemedicine capability
EP1166222A2 (en) 1999-04-01 2002-01-02 ACIST Medical Systems, Inc. An integrated medical information management and medical device control system and method
AU5133700A (en) 1999-05-17 2000-12-05 Pharmacon Global Enterprises, Llc Data processing system for patient outcome and risk benchmarking and healthcare data base management
US8175895B2 (en) 1999-06-23 2012-05-08 Koninklijke Philips Electronics N.V. Remote command center for patient monitoring
US6277071B1 (en) 1999-06-25 2001-08-21 Delphi Health Systems, Inc. Chronic disease monitor
US6923763B1 (en) 1999-08-23 2005-08-02 University Of Virginia Patent Foundation Method and apparatus for predicting the risk of hypoglycemia
US6688891B1 (en) 1999-08-27 2004-02-10 Inter-Tares, Llc Method and apparatus for an electronic collaborative education process model
DE10006044A1 (de) 2000-02-10 2001-08-16 Roche Diagnostics Gmbh Anordnung und Verfahren zur Dosierung eines die Blutglukose eines Patienten regulierenden Hormons
US20030036683A1 (en) 2000-05-01 2003-02-20 Kehr Bruce A. Method, system and computer program product for internet-enabled, patient monitoring system
WO2001088810A1 (en) 2000-05-12 2001-11-22 Opsion Medical, Inc. Networked medical information system for clinical practices
GB0012840D0 (en) 2000-05-25 2000-07-19 Thirdphase Limited Method and system for collection and verification of data from plural sites
BRPI0414359A (pt) 2000-06-16 2006-11-14 Bodymedia Inc sistema para a monitoração e gerenciamento do peso corpóreo e demais condições psicológicas que abrangem um planejamento interativo e personalizado, intervenção e capacidade de formular relatórios
WO2002015777A1 (en) 2000-08-18 2002-02-28 Cygnus, Inc. Methods and devices for prediction of hypoglycemic events
WO2002018936A2 (en) 2000-08-28 2002-03-07 Cygnus, Inc. Methods of monitoring glucose levels in a subject and uses thereof
WO2005098429A2 (en) 2000-11-08 2005-10-20 University Of Florida Research Foundation, Inc. System and method for real-time diagnosis, treatment, and therapeutic drug monitoring
US7756722B2 (en) 2001-02-01 2010-07-13 Georgetown University Clinical management system from chronic illnesses using telecommunication
KR20030014387A (ko) * 2001-02-08 2003-02-17 인버니스 메디칼 리미티드 개인 건강상태 관리 시스템
US20030074248A1 (en) 2001-03-31 2003-04-17 Braud Kristopher P. Method and system for assimilating data from disparate, ancillary systems onto an enterprise system
US20020183965A1 (en) 2001-05-02 2002-12-05 Gogolak Victor V. Method for analyzing drug adverse effects employing multivariate statistical analysis
US7353152B2 (en) 2001-05-02 2008-04-01 Entelos, Inc. Method and apparatus for computer modeling diabetes
US20060235280A1 (en) 2001-05-29 2006-10-19 Glenn Vonk Health care management system and method
US20030028482A1 (en) 2001-07-05 2003-02-06 Burak Carl S. Method and apparatus for accounting and billing for telecommunicatively rendered services
US6544212B2 (en) 2001-07-31 2003-04-08 Roche Diagnostics Corporation Diabetes management system
US7001739B2 (en) 2001-08-24 2006-02-21 The Texas A&M University System Isolation of proteins involved in posttranscriptional gene silencing and methods of use
US6691043B2 (en) 2001-08-28 2004-02-10 Maxi-Med, Llc Bolus calculator
US7529685B2 (en) 2001-08-28 2009-05-05 Md Datacor, Inc. System, method, and apparatus for storing, retrieving, and integrating clinical, diagnostic, genomic, and therapeutic data
DK1436023T3 (da) 2001-09-07 2013-02-18 Medtronic Minimed Inc Sikkerhedsgrænser for en fusionspumpestyring med lukket kredsløb
US20030065669A1 (en) 2001-10-03 2003-04-03 Fasttrack Systems, Inc. Timeline forecasting for clinical trials
US20030093294A1 (en) 2001-11-09 2003-05-15 Passantino Philip J. System providing expanded expert and electronic consultations for clients
US20030115214A1 (en) 2001-12-17 2003-06-19 Nir Essar Medical reporting system and method
US7022072B2 (en) 2001-12-27 2006-04-04 Medtronic Minimed, Inc. System for monitoring physiological characteristics
US6744350B2 (en) 2002-02-28 2004-06-01 Smiths Medical Md, Inc. Insulin pump having missed meal bolus alarm
GB0206792D0 (en) 2002-03-22 2002-05-01 Leuven K U Res & Dev Normoglycemia
EP1382363A1 (en) 2002-07-15 2004-01-21 Novo Nordisk A/S Closed loop system for controlling blood glucose levels
CA2495648C (en) 2002-08-13 2014-07-22 University Of Virginia Patent Foundation Method, system, and computer program product for processing of self-monitoring blood glucose (smbg) data to enhance diabetic self-management
WO2004016156A2 (en) 2002-08-16 2004-02-26 The Regents Of The University Of California Dynamic hepatic recycling glucose tolerance test
US20050031094A1 (en) 2002-09-19 2005-02-10 Gilbert Quenton L. System and method for message delivery to a busy called party
US20040122530A1 (en) 2002-09-30 2004-06-24 Steffen Hansen Indicating device with estimating feature
DE60328039D1 (de) 2002-10-11 2009-07-30 Becton Dickinson Co Insulinabgabesystem mit Sensor
US9872890B2 (en) 2003-03-19 2018-01-23 Paul C. Davidson Determining insulin dosing schedules and carbohydrate-to-insulin ratios in diabetic patients
US20050038326A1 (en) 2003-05-30 2005-02-17 Michael Mathur System, device, and method for remote monitoring and servicing
US7627334B2 (en) 2003-07-21 2009-12-01 Contextual Information, Inc. Systems and methods for context relevant information management and display
DE602004000677T2 (de) 2003-08-15 2007-05-10 Research In Motion Ltd., Waterloo Bestimmung der Aktivierungszeit für eine Aufwärtsrichtungsverschlüsselung in einem UMTS Teilnehmergerät
US20050203001A1 (en) 2004-03-05 2005-09-15 Emisphere Technologies, Inc. Oral insulin therapies and protocol
CA2540280A1 (en) 2003-10-07 2005-04-21 Entelos, Inc. Simulating patient-specific outcomes
US20050107318A1 (en) 2003-11-17 2005-05-19 Samuel Wadsworth Methods of treating diabetes and other blood sugar disorders
GB0329288D0 (en) 2003-12-18 2004-01-21 Inverness Medical Switzerland Monitoring method and apparatus
US20050137910A1 (en) 2003-12-19 2005-06-23 Rao R. B. Systems and methods for automated extraction and processing of billing information in patient records
CA2833776C (en) 2004-02-26 2017-03-28 Diabetes Tools Sweden Ab Metabolic monitoring, a method and apparatus for indicating a health-related condition of a subject
WO2005102155A1 (en) 2004-04-22 2005-11-03 Medtronic Minimed, Inc. Infusion devices, glucose meters and/or monitors with smell sniffing technology
WO2005113036A1 (en) * 2004-05-13 2005-12-01 The Regents Of The University Of California Method and apparatus for glucose control and insulin dosing for diabetics
JP4781710B2 (ja) * 2005-05-12 2011-09-28 シスメックス株式会社 治療効果予測システム及びそのプログラム
US20060272652A1 (en) 2005-06-03 2006-12-07 Medtronic Minimed, Inc. Virtual patient software system for educating and treating individuals with diabetes
US20060276771A1 (en) 2005-06-06 2006-12-07 Galley Paul J System and method providing for user intervention in a diabetes control arrangement
JP4861687B2 (ja) 2005-11-21 2012-01-25 シスメックス株式会社 医療用シミュレーションシステム及びそのコンピュータプログラム
US7941200B2 (en) 2005-12-08 2011-05-10 Roche Diagnostics Operations, Inc. System and method for determining drug administration information
US20070288266A1 (en) 2006-06-02 2007-12-13 Suzanne Sysko System and methods for chronic disease management and health assessment

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200168313A1 (en) * 2017-07-28 2020-05-28 W.O.M. World Of Medicine Gmbh Medical engineering apparatus for storing and evaluating clinical data
WO2023135346A1 (es) 2022-01-12 2023-07-20 Universidad Complutense De Madrid Método y sistema para predicción de valores de glucosa y generación de alertas de hipoglucemia e hiperglucemia

Also Published As

Publication number Publication date
WO2009002620A1 (en) 2008-12-31
JP5529307B2 (ja) 2014-06-25
JP2010532044A (ja) 2010-09-30
CN101689224A (zh) 2010-03-31
CN101689224B (zh) 2015-06-17
EP2562664A3 (en) 2013-09-18
EP2562664B1 (en) 2020-11-25
KR20100027165A (ko) 2010-03-10
KR101347008B1 (ko) 2014-01-02
US8818782B2 (en) 2014-08-26
JP2013122790A (ja) 2013-06-20
KR20130010037A (ko) 2013-01-24
CA2687562A1 (en) 2008-12-31
JP5209714B2 (ja) 2013-06-12
EP2562664A2 (en) 2013-02-27
EP2171630A1 (en) 2010-04-07
US20090006061A1 (en) 2009-01-01
DK2562664T3 (da) 2021-02-01
CA2687562C (en) 2015-11-24
KR101423807B1 (ko) 2014-07-30
HK1142421A1 (en) 2010-12-03

Similar Documents

Publication Publication Date Title
ES2845400T3 (es) Sistema para determinar una administración de insulina y comunicar una dosis en un programa informático de páncreas automatizado
ES2733350T3 (es) Sistema para el diagnóstico, tratamiento y pronóstico médicos para acontecimientos solicitados y procedimiento del mismo
Parimbelli et al. Trusting telemedicine: a discussion on risks, safety, legal implications and liability of involved stakeholders
EP2710502B1 (en) Dynamic data collection
Bas STPA methodology in a socio-technical system of monitoring and tracking diabetes mellitus
Georga et al. Personalized predictive modeling in type 1 diabetes
Carson Decision support systems in diabetes: a systems perspective
An Towards the clinical translation of a physiological closed-loop control system for precise control of propofol-induced pharmacological coma
HK1147814B (en) Medical diagnosis, therapy, and prognosis system for invoked events and method thereof
HK1142421B (en) System and method for developing patient specific therapies based on modeling of patient physiology
HK1172107B (en) Adherence indication tool for chronic disease management and method thereof
HK1194166A (en) Dynamic data collection
HK1172107A1 (zh) 用於慢性病管理的遵守性指示工具及其方法
HK1194166B (zh) 动态数据收集
HK1144718A1 (en) Therapy delivery system having an open architecture and a method thereof
HK1144718B (en) Therapy delivery system having an open architecture and a method thereof
HK1144660A (en) Patient information input interface for a therapy system