ES2741173T3 - Protocolo de comunicación que soporta comunicación de transferencia - Google Patents
Protocolo de comunicación que soporta comunicación de transferencia Download PDFInfo
- Publication number
- ES2741173T3 ES2741173T3 ES11804960T ES11804960T ES2741173T3 ES 2741173 T3 ES2741173 T3 ES 2741173T3 ES 11804960 T ES11804960 T ES 11804960T ES 11804960 T ES11804960 T ES 11804960T ES 2741173 T3 ES2741173 T3 ES 2741173T3
- Authority
- ES
- Spain
- Prior art keywords
- transfer
- instruction
- diabetes
- medical device
- data packet
- 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
Links
- 238000012546 transfer Methods 0.000 title claims abstract description 213
- 230000006854 communication Effects 0.000 title claims abstract description 212
- 238000004891 communication Methods 0.000 title claims abstract description 212
- 206010012601 diabetes mellitus Diseases 0.000 claims abstract description 215
- 230000004044 response Effects 0.000 claims abstract description 65
- 230000007175 bidirectional communication Effects 0.000 claims abstract description 23
- NOESYZHRGYRDHS-UHFFFAOYSA-N insulin Chemical compound N1C(=O)C(NC(=O)C(CCC(N)=O)NC(=O)C(CCC(O)=O)NC(=O)C(C(C)C)NC(=O)C(NC(=O)CN)C(C)CC)CSSCC(C(NC(CO)C(=O)NC(CC(C)C)C(=O)NC(CC=2C=CC(O)=CC=2)C(=O)NC(CCC(N)=O)C(=O)NC(CC(C)C)C(=O)NC(CCC(O)=O)C(=O)NC(CC(N)=O)C(=O)NC(CC=2C=CC(O)=CC=2)C(=O)NC(CSSCC(NC(=O)C(C(C)C)NC(=O)C(CC(C)C)NC(=O)C(CC=2C=CC(O)=CC=2)NC(=O)C(CC(C)C)NC(=O)C(C)NC(=O)C(CCC(O)=O)NC(=O)C(C(C)C)NC(=O)C(CC(C)C)NC(=O)C(CC=2NC=NC=2)NC(=O)C(CO)NC(=O)CNC2=O)C(=O)NCC(=O)NC(CCC(O)=O)C(=O)NC(CCCNC(N)=N)C(=O)NCC(=O)NC(CC=3C=CC=CC=3)C(=O)NC(CC=3C=CC=CC=3)C(=O)NC(CC=3C=CC(O)=CC=3)C(=O)NC(C(C)O)C(=O)N3C(CCC3)C(=O)NC(CCCCN)C(=O)NC(C)C(O)=O)C(=O)NC(CC(N)=O)C(O)=O)=O)NC(=O)C(C(C)CC)NC(=O)C(CO)NC(=O)C(C(C)O)NC(=O)C1CSSCC2NC(=O)C(CC(C)C)NC(=O)C(NC(=O)C(CCC(N)=O)NC(=O)C(CC(N)=O)NC(=O)C(NC(=O)C(N)CC=1C=CC=CC=1)C(C)C)CC1=CN=CN1 NOESYZHRGYRDHS-UHFFFAOYSA-N 0.000 claims description 106
- 102000004877 Insulin Human genes 0.000 claims description 53
- 108090001061 Insulin Proteins 0.000 claims description 53
- 229940125396 insulin Drugs 0.000 claims description 53
- WQZGKKKJIJFFOK-GASJEMHNSA-N Glucose Natural products OC[C@H]1OC(O)[C@H](O)[C@@H](O)[C@@H]1O WQZGKKKJIJFFOK-GASJEMHNSA-N 0.000 claims description 42
- 239000008103 glucose Substances 0.000 claims description 42
- 238000012806 monitoring device Methods 0.000 abstract description 6
- 238000012544 monitoring process Methods 0.000 abstract description 2
- 239000008280 blood Substances 0.000 description 35
- 210000004369 blood Anatomy 0.000 description 35
- 239000003795 chemical substances by application Substances 0.000 description 34
- 238000000034 method Methods 0.000 description 30
- 230000036541 health Effects 0.000 description 23
- 230000009471 action Effects 0.000 description 19
- 230000005540 biological transmission Effects 0.000 description 15
- 238000012545 processing Methods 0.000 description 13
- 230000015654 memory Effects 0.000 description 12
- 238000010586 diagram Methods 0.000 description 11
- 238000007726 management method Methods 0.000 description 10
- 238000005259 measurement Methods 0.000 description 10
- 230000008569 process Effects 0.000 description 8
- 239000011159 matrix material Substances 0.000 description 7
- 238000002560 therapeutic procedure Methods 0.000 description 7
- 238000001802 infusion Methods 0.000 description 5
- 230000000694 effects Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000036772 blood pressure Effects 0.000 description 3
- 238000004590 computer program Methods 0.000 description 3
- 238000010276 construction Methods 0.000 description 3
- 201000010099 disease Diseases 0.000 description 3
- 208000037265 diseases, disorders, signs and symptoms Diseases 0.000 description 3
- 238000005192 partition Methods 0.000 description 3
- 230000032258 transport Effects 0.000 description 3
- 208000017667 Chronic Disease Diseases 0.000 description 2
- 206010018429 Glucose tolerance impaired Diseases 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 150000001720 carbohydrates Chemical class 0.000 description 2
- 235000014633 carbohydrates Nutrition 0.000 description 2
- HVYWMOMLDIMFJA-DPAQBDIFSA-N cholesterol Chemical compound C1C=C2C[C@@H](O)CC[C@]2(C)[C@@H]2[C@@H]1[C@@H]1CC[C@H]([C@H](C)CCCC(C)C)[C@@]1(C)CC2 HVYWMOMLDIMFJA-DPAQBDIFSA-N 0.000 description 2
- 238000013479 data entry Methods 0.000 description 2
- 230000034994 death Effects 0.000 description 2
- 231100000517 death Toxicity 0.000 description 2
- 230000037213 diet Effects 0.000 description 2
- 235000005911 diet Nutrition 0.000 description 2
- 235000012054 meals Nutrition 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 229940126701 oral medication Drugs 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000001052 transient effect Effects 0.000 description 2
- 201000004569 Blindness Diseases 0.000 description 1
- 208000002249 Diabetes Complications Diseases 0.000 description 1
- 241000283899 Gazella Species 0.000 description 1
- 208000002705 Glucose Intolerance Diseases 0.000 description 1
- 208000001145 Metabolic Syndrome Diseases 0.000 description 1
- 241000208125 Nicotiana Species 0.000 description 1
- 235000002637 Nicotiana tabacum Nutrition 0.000 description 1
- 208000008589 Obesity Diseases 0.000 description 1
- 241000791420 Plica Species 0.000 description 1
- 206010035664 Pneumonia Diseases 0.000 description 1
- 208000001280 Prediabetic State Diseases 0.000 description 1
- 208000001647 Renal Insufficiency Diseases 0.000 description 1
- 208000006011 Stroke Diseases 0.000 description 1
- 206010067584 Type 1 diabetes mellitus Diseases 0.000 description 1
- 101100386506 Xenopus laevis dazap1 gene Proteins 0.000 description 1
- 201000000690 abdominal obesity-metabolic syndrome Diseases 0.000 description 1
- 238000002266 amputation Methods 0.000 description 1
- 230000001363 autoimmune Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- WQZGKKKJIJFFOK-VFUOTHLCSA-N beta-D-glucose Chemical compound OC[C@H]1O[C@@H](O)[C@H](O)[C@@H](O)[C@@H]1O WQZGKKKJIJFFOK-VFUOTHLCSA-N 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 210000001124 body fluid Anatomy 0.000 description 1
- 239000010839 body fluid Substances 0.000 description 1
- 230000037396 body weight Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 229940079593 drug Drugs 0.000 description 1
- 239000003814 drug Substances 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 235000013305 food Nutrition 0.000 description 1
- 230000037406 food intake Effects 0.000 description 1
- 235000012631 food intake Nutrition 0.000 description 1
- 230000002068 genetic effect Effects 0.000 description 1
- 208000004104 gestational diabetes Diseases 0.000 description 1
- 230000006377 glucose transport Effects 0.000 description 1
- 208000019622 heart disease Diseases 0.000 description 1
- 206010022000 influenza Diseases 0.000 description 1
- 201000006370 kidney failure Diseases 0.000 description 1
- 238000002483 medication Methods 0.000 description 1
- 230000005906 menstruation Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 235000020824 obesity Nutrition 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 201000009104 prediabetes syndrome Diseases 0.000 description 1
- 230000035935 pregnancy Effects 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 102000004169 proteins and genes Human genes 0.000 description 1
- 108090000623 proteins and genes Proteins 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000007920 subcutaneous administration Methods 0.000 description 1
- 150000003626 triacylglycerols Chemical class 0.000 description 1
- 208000001072 type 2 diabetes mellitus Diseases 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
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
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
- G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/14—Direct-mode setup
Landscapes
- Health & Medical Sciences (AREA)
- Engineering & Computer Science (AREA)
- Biomedical Technology (AREA)
- General Health & Medical Sciences (AREA)
- Public Health (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Primary Health Care (AREA)
- Medical Informatics (AREA)
- Epidemiology (AREA)
- General Business, Economics & Management (AREA)
- Business, Economics & Management (AREA)
- Vascular Medicine (AREA)
- Animal Behavior & Ethology (AREA)
- Veterinary Medicine (AREA)
- Life Sciences & Earth Sciences (AREA)
- Hematology (AREA)
- Heart & Thoracic Surgery (AREA)
- Anesthesiology (AREA)
- Diabetes (AREA)
- Infusion, Injection, And Reservoir Apparatuses (AREA)
Abstract
Un sistema de control de diabetes configurado para permitir comunicación de transferencia que comprende: - un dispositivo de control de diabetes (104, 500); - un dispositivo informático externo (600) que comunica con el dispositivo de control de diabetes (104, 500) a través de un primer enlace de comunicaciones bidireccional, en el que el dispositivo de control de diabetes (104, 500) y el dispositivo informático externo (600) intercambian primeros paquetes de datos de una primera estructura de paquete de datos a través del primer enlace de comunicación bidireccional; - un primer dispositivo médico (700) que realiza una tarea relacionada con control de diabetes y que comunica con el dispositivo de control de diabetes (104, 500) a través de un segundo enlace de comunicaciones bidireccional; en el que el dispositivo de control de diabetes (104, 500) y el primer dispositivo médico (700) intercambian segundos paquetes de datos de una segunda estructura de paquete de datos a través del segundo enlace de comunicación bidireccional; el dispositivo de control de diabetes (104, 500) que incluye un módulo de transferencia (512) que: - establece una trayectoria de comunicación de transferencia entre el dispositivo informático externo (600) y el primer dispositivo médico (700), - recibe primeros paquetes de datos de la primera estructura de paquete de datos desde el dispositivo informático externo (600) a través del primer enlace de comunicaciones bidireccional, - convierte los primeros paquetes de datos en segundos paquetes de datos de la segunda estructura de paquete de datos, y - transmite los segundos paquetes de datos al primer dispositivo médico (700) a través del segundo enlace de comunicaciones bidireccional; en el que el módulo de transferencia (512) usa un conjunto de instrucciones de transferencia para establecer una trayectoria de comunicación de transferencia y habilitar comunicación entre el dispositivo informático externo (600) y el primer dispositivo médico (700), caracterizado por que - el conjunto de instrucciones de transferencia se define como una extensión privada de la norma de IEEE 11073- 20601, - el conjunto de instrucciones de transferencia incluye una instrucción de transmitir carga útil de transferencia recibida desde el dispositivo informático externo (600), en el que la instrucción de transmitir carga útil de transferencia - ordena al dispositivo de control de diabetes (104, 500) que transmita una carga útil del primer paquete de datos desde el dispositivo informático externo (600) al primer dispositivo médico (700), y - incluye la carga útil del primer paquete de datos, y - el módulo de transferencia (512), en respuesta a la instrucción de transmitir carga útil de transferencia, genera el segundo paquete de datos insertando la carga útil del primer paquete de datos en el segundo paquete de datos, y transmite el segundo paquete de datos al primer dispositivo médico (700) a través del segundo enlace de comunicación.
Description
DESCRIPCIÓN
Protocolo de comunicación que soporta comunicación de transferencia
Campo
La presente divulgación se refiere a un protocolo de comunicación para dispositivos médicos usados para el cuidado de la diabetes y, más particularmente, a un protocolo de comunicación que soporta comunicación de transferencia entre un dispositivo informático externo y un dispositivo médico usado en el tratamiento de la diabetes a través de un dispositivo de control de diabetes.
Antecedentes
La diabetes mellitus, a menudo denominada como diabetes, es una condición crónica en la que una persona tiene niveles de glucosa en sangre elevados que resultan de defectos en la capacidad del cuerpo para producir y/o usar insulina. Existen tres tipos principales de diabetes. Diabetes tipo 1 normalmente ataca a niños y adultos jóvenes, y puede ser autoinmune, genética y/o ambiental. Diabetes tipo 2 representa el 90-95 % de casos de diabetes y está vinculada a obesidad e inactividad física. La diabetes gestacional es una forma de intolerancia a la glucosa diagnosticada durante el embarazo y normalmente se corrige espontáneamente después del parto.
En 2009, de acuerdo con la Organización Mundial de la Salud, al menos 220 millones de personas en todo el mundo padecen diabetes. En 2005, se estima que 1,1 millones de personas murieron de diabetes. Su incidencia está creciendo rápidamente y se estima que entre 2005 y 2030, el número de muertes por diabetes se doblará. En los Estados Unidos, casi 24 millones de estadounidenses tienen diabetes con una estimación del 25 por ciento de ancianos de 60 y más años afectados. Los Centros de Control y Prevención de Enfermedades prevén que 1 de cada 3 estadounidenses nacidos después de 2000 desarrollarán diabetes durante su vida. El Centro Nacional de Información sobre la Diabetes estima que la diabetes cuesta 132 $ miles de millones cada año solo en los Estados Unidos. Sin tratamiento, la diabetes puede conducir a complicaciones graves como enfermedades de corazón, derrame cerebral, ceguera, fallo renal, amputaciones y muerte relacionada con neumonía y gripe.
El control de la diabetes es complejo ya que el nivel de glucosa en sangre que entra en el torrente sanguíneo es dinámico. La variación de insulina en el torrente sanguíneo que controla el transporte de glucosa fuera del torrente sanguíneo también complica el control de diabetes. Los niveles de glucosa en sangre son sensibles a la dieta y ejercicio, pero también pueden verse afectados por sueño, estrés, tabaco, viajes, enfermedades, menstruación y otros factores psicológicos y de estilo de vida únicos a pacientes individuales. La naturaleza dinámica de la glucosa en sangre e insulina, y todos los otros factores que afectan a la glucosa en sangre, a menudo requiere que una persona con diabetes prevea niveles de glucosa en sangre. Por lo tanto, terapia en forma de insulina o medicaciones por vía oral, o ambas, pueden programarse para mantener niveles de glucosa en sangre dentro de un intervalo apropiado.
El control de la diabetes a menudo es altamente intrusivo debido a la necesidad de obtener consistentemente información de diagnóstico fiable, seguir la terapia prescrita y control del estilo de vida de forma diaria. Información de diagnóstico diaria, tal como concentración de glucosa en sangre, habitualmente se obtiene a partir de una muestra de sangre capilar con un dispositivo de punción y a continuación se mide con un medidor de glucosa en sangre de mano. Los niveles de glucosa intersticial pueden obtenerse a partir de un sensor de glucosa continuo llevado en el cuerpo. Terapias prescritas pueden incluir insulina, medicaciones por vía oral, o ambas. La insulina puede suministrarse con una jeringuilla, una bomba de infusión ambulatoria o una combinación de ambas. Con la terapia de insulina, determinar la cantidad de insulina a inyectar puede requerir prever la composición de la comida de grasa, carbohidratos y proteínas junto con efectos de ejercicio u otros estados psicológicos. El control de los factores de estilo de vida tal como peso corporal dieta y ejercicio pueden influenciar significativamente el tipo y efectividad de una terapia.
El control de diabetes implica grandes cantidades de datos de diagnóstico y datos prescriptivos que se adquieren de dispositivos médicos, dispositivos de salud personal, información de paciente registrada, resultados de pruebas de profesionales de salud, medicaciones prescritas e información registrada. Los pacientes con diabetes y sus profesionales de la salud interactúan con una diversidad de dispositivos médicos y sistemas para ayudar a controlar la enfermedad, incluyendo realizar procedimientos de recopilación estructurados. Para cada uno de estos distintos tipos de dispositivos médicos, existe una necesidad de agregar, manipular, gestionar, presentar y comunicar datos de diagnóstico y datos prescriptivos de múltiples fuentes de datos de una manera eficiente para mejorar el cuidado y salud de una persona con diabetes, de forma que la persona con diabetes puede llevar una vida plena y reducir el riesgo de complicaciones de la diabetes. También existe una necesidad de agregar, manipular, gestionar, presentar y comunicar tales datos de diagnóstico y datos prescriptivos entre los diferentes tipos de dispositivos médicos usando un protocolo de comunicación estándar. IEEE 11073 es una norma de comunicación ilustrativa que aborda la interoperabilidad y comunicación entre dispositivos médicos tal como monitores de presión sanguínea, monitores de glucosa en sangre y similares. Dentro del contexto de tales protocolos de comunicación, existe adicionalmente la necesidad de soportar características de comunicación avanzadas, tal como comunicaciones entre dispositivos no configurados para comunicarse directamente entre sí.
El documento US 2002/0193679 A1 divulga una estación de comunicación para uso con un dispositivo médico y un dispositivo de procesamiento. La estación de comunicación tiene una interfaz de dispositivo para interactuar con el dispositivo médico y una interfaz de dispositivo de procesamiento para interactuar con el dispositivo de procesamiento. La estación de comunicación proporciona una trayectoria de comunicación entre el dispositivo médico y el dispositivo de procesamiento.
El documento US 2001/0097908 A1 divulga un sistema y un método para el procesamiento y transmisión de datos médicos a través de un dispositivo. El dispositivo recibe datos y procesa los datos en un formato compatible con el dispositivo médico.
El documento US 2007/0055799 A1 divulga un adaptador de comunicación para uso con un dispositivo médico ambulante. El dispositivo médico transfiere datos al adaptador de comunicación que transmite los datos a un ordenador por medio de una conexión de datos. El adaptador de comunicación se configura para procesar los datos recibidos desde el dispositivo médico.
La descripción de antecedentes proporcionada en este documento es para el propósito de presentar en general el contexto de la divulgación.
Sumario
La presente invención divulga un sistema de control de diabetes según se define mediante reivindicaciones 1-7. En una realización, un primer enlace de comunicación es un enlace de comunicación por cable y un segundo enlace de comunicación es un enlace de comunicación inalámbrico. En otra realización, el primer dispositivo médico es uno de una bomba de insulina durable, una bomba de insulina no durable, un monitor de glucosa continuo y un dispositivo móvil.
Breve descripción de los dibujos
La Figura 1 es un diagrama que muestra un paciente y un clínico tratante;
La Figura 2 es un diagrama que muestra al paciente con un monitor de glucosa continuo (CGM), una bomba de infusión de insulina durable ambulatoria, la bomba de infusión de insulina no durable ambulatoria y un controlador de diabetes;
La Figura 3 es un diagrama de bloques que muestra un sistema de control de diabetes ilustrativo usado por pacientes y clínicos para controlar la diabetes;
La Figura 4 es un diagrama de bloques funcional de un controlador de diabetes;
La Figura 5 es un diagrama de bloques que muestra un dispositivo de control de diabetes ilustrativo configurado para efectuar comunicación de transferencia;
La Figura 6 es un diagrama de bloques que muestra un dispositivo informático externo ilustrativo configurado para comunicarse con un dispositivo de control de diabetes ilustrativo;
La Figura 7 es un diagrama de bloques que muestra un dispositivo médico ilustrativo configurado para comunicarse con un dispositivo de control de diabetes ilustrativo;
La Figura 8 es un diagrama de bloques que muestra un sistema de control de diabetes ilustrativo que soporta comunicación de transferencia entre un dispositivo informático externo y un dispositivo médico;
La Figura 9 es un diagrama de bloques que representa cómo la extensión privada del solicitante se refiere a los protocolos de comunicación normalizados;
Las Figuras 10A y 10B son un diagrama de flujo que ilustra un método para realizar comunicación de transferencia; y
la Figura 11 es un diagrama de clase para un dispositivo de salud personal definido de acuerdo con ISO/IEEE 11073-20601.
Los dibujos descritos en este documento son únicamente para propósitos de ilustración de realizaciones seleccionadas y no todas las implementaciones posibles, y no pretenden limitar el alcance de la presente divulgación. Números de referencia correspondientes indican partes correspondientes a través de las varias vistas de los dibujos.
Descripción detallada
Haciendo referencia a la Figura 1, se muestran una persona 100 con diabetes y un profesional de la salud 102 en un entorno clínico. Personas con diabetes incluyen personas con síndrome metabólico, prediabetes, diabéticos tipo 1, diabéticos tipo 2 y diabéticos gestacionales y se denominan colectivamente como un paciente. Proveedores de asistencia sanitaria para diabetes son varios e incluyen enfermeras, enfermeras practicantes, médicos y endocrinólogos y se denominan colectivamente como un clínico.
Durante una consulta sanitaria, el paciente 100 habitualmente comparte con el clínico 102 una diversidad de datos de paciente que incluyen mediciones de glucosa en sangre, datos de monitor de glucosa continuo, cantidades de insulina infundida, cantidades de comida y bebida consumidas, horarios de ejercicio y otra información del estilo de vida. El clínico 102 puede obtener datos de paciente adicionales que incluyen mediciones de HbAlC, niveles de colesterol, triglicéridos, presión sanguínea y peso del paciente 100. Los datos de paciente pueden registrarse manual o electrónicamente en un dispositivo de control de diabetes de mano 104, un software de análisis de diabetes ejecutado en un ordenador personal (PC) 106 y/o a un sitio basado en web de análisis de diabetes (no mostrado). El clínico 102 puede analizar los datos de paciente manual o electrónicamente usando el software de análisis de diabetes y/o el sitio basado en web de análisis de diabetes. Después de analizar los datos de paciente y revisar el cumplimiento del paciente 100 a la terapia prescrita anteriormente, el clínico 102 puede decide si modificar la terapia para el paciente 100.
Haciendo referencia a la Figura 2, el paciente 100 puede usar un monitor de glucosa continuo (CGM) 200, una bomba de infusión de insulina no durable ambulatoria 202 o una bomba de infusión de insulina durable ambulatoria 204 (en lo sucesivo bomba de insulina 202 o 204) y el dispositivo de control de diabetes de mano 104 (en lo sucesivo el controlador de diabetes 104). El CGM 200 usa un sensor subcutáneo para detectar y supervisar la cantidad de glucosa en la sangre del paciente 100 y comunica correspondientes lecturas al controlador de diabetes 104.
El controlador de diabetes 104 realiza diversas tareas que incluyen la medición y grabación de niveles de glucosa en sangre, determinación de una cantidad de insulina a administrarse al paciente 100 a través de la bomba de insulina 202 o 204, recepción de datos de paciente a través de una interfaz de usuario, archivo de los datos de paciente, etc. El controlador de diabetes 104 recibe periódicamente lecturas del CGM 200 que indican nivel de insulina en la sangre del paciente 100. El controlador de diabetes 104 transmite instrucciones a la bomba de insulina 202 o 204, que suministra insulina al paciente 100. La insulina puede suministrarse de una manera planificada en forma de una dosis basal, que mantiene un nivel de insulina predeterminado en la sangre del paciente 100. Adicionalmente, la insulina puede suministrarse en forma de a dosis de bolo, que eleva la cantidad de insulina en la sangre del paciente 100 en una cantidad predeterminada.
Haciendo referencia a la Figura 3, un sistema de control de diabetes 300 usado por el paciente 100 y el clínico 102 incluye uno o más de los siguientes dispositivos: el controlador de diabetes 104, el monitor de glucosa continuo (CGM) 200, la bomba de insulina 202 o 204, un dispositivo móvil 302, el PC 106 con el software de análisis de diabetes y otros dispositivos de salud 304. El controlador de diabetes 104 se configura como un concentrador de sistema y comunica con los dispositivos del sistema de control de diabetes 300. Como alternativa, la bomba de insulina 204 o el dispositivo móvil 302 puede servir como el concentrador de sistema. La comunicación entre los dispositivos en el sistema de control de diabetes 300 puede realizarse usando interfaces inalámbricas (por ejemplo, Bluetooth) y/o interfaces por cable (por ejemplo, USB). Protocolos de comunicación usados por estos dispositivos pueden incluir protocolos que cumplen con la norma IEEE 11073 como directrices de uso extendidas proporcionadas por las directrices de diseño de la Continual Health Alliance. Además, pueden usarse sistemas de registro de salud tales como Microsoft® HealthVault™ y Google™ Health por el paciente 100 y clínico 102 para intercambiar información.
El controlador de diabetes 104 puede recibir lecturas de glucosa en sangre desde una o más fuentes (por ejemplo, desde el CGM 200). El CGM 200 mide continuamente el nivel de glucosa en sangre del paciente 100. El c Gm 200 comunica periódicamente el nivel de glucosa en sangre al controlador de diabetes 104. El controlador de diabetes 104 y el CGM 200 se comunican inalámbricamente usando un protocolo inalámbrico propietario (por ejemplo, protocolo inalámbrico Gazell de Nordic Semiconductor, Inc.).
Adicionalmente, el controlador de diabetes 104 incluye un medidor de glucosa en sangre (BGM) y un puerto que comunica con el BGM (no mostrado). El puerto puede recibir una tira de medición de glucosa en sangre 306. El paciente 100 deposita una muestra de sangre u otro fluido corporal en la tira de medición de glucosa en sangre 306. El BGM analiza la muestra y mide el nivel de glucosa en sangre en la muestra. El nivel de glucosa en sangre medido a partir de la muestra y/o el nivel de glucosa en sangre leído por el CGM 200 puede usarse para determinar la cantidad de insulina a administrar al paciente 100. Para facilitar la recopilación de medidas de glucosa en sangre, el controlador de diabetes 104 puede ejecutar uno o más procedimientos de recopilación estructurada como se describe adicionalmente a continuación.
El controlador de diabetes 104 comunica con la bomba de insulina 202 o 204. La bomba de insulina 202 o 204 puede configurarse para recibir instrucciones desde el controlador de diabetes 104 para suministrar una cantidad predeterminada de insulina al paciente 100. Adicionalmente, el controlador de diabetes 104 puede recibir otra información desde el paciente incluyendo horarios de comidas y/o ejercicio del paciente 100. El controlador de diabetes 104 puede determinar la cantidad de insulina a administrar basándose en la información adicional.
La bomba de insulina 202 o 204 también puede comunicar datos al controlador de diabetes 104. Los datos pueden incluir cantidades de insulina suministrada al paciente 100, correspondientes momentos de suministro y estado de bomba. El controlador de diabetes 104 y la bomba de insulina 202 o 204 pueden comunicarse usando un protocolo de comunicación inalámbrica tal como Bluetooth. También puede usarse otros protocolos de comunicación inalámbricos o por cable.
Además, el controlador de diabetes 104 puede comunicarse con los otros dispositivos de salud 304. Por ejemplo, los otros dispositivos de salud 304 pueden incluir un medidor de presión sanguínea, una báscula, un podómetro, un oxímetro de pulso, un termómetro, etc. Los otros dispositivos de salud 304 obtienen y comunican información de salud personal del paciente 100 al controlador de diabetes 104 a través de interfaces inalámbricas, USB u otras interfaces. Los otros dispositivos de salud 304 pueden usar protocolos de comunicación que cumplen con ISO/IEEE 11073. El controlador de diabetes 104 puede comunicarse con los otros dispositivos de salud 304 usando interfaces que incluyen Bluetooth, USB, etc. Además, los dispositivos del sistema de control de diabetes 300 pueden comunicarse entre sí a través del controlador de diabetes 104.
El controlador de diabetes 104 puede comunicarse con el PC 106 usando USB u otras interfaces por cable o inalámbricas, tal como Bluetooth. Un software de control de diabetes que se ejecuta en el PC 106 incluye una aplicación de gestión de dispositivo y una aplicación de control de diabetes. En algunas realizaciones, las aplicaciones pueden combinarse en un analizador-configurador que almacena información de configuración de los dispositivos del sistema de control de diabetes 300. El configurador tiene una base de datos para almacenar información de configuración del controlador de diabetes 104 y los otros dispositivos. El configurador puede comunicarse con usuarios a través de pantallas de ordenador o web estándar en aplicaciones no web. El configurador transmite configuraciones aprobadas por usuario a los dispositivos del sistema de control de diabetes 300. El analizador recupera datos del controlador de diabetes 104, almacena los datos en una base de datos y emite resultados de análisis a través de páginas web estándar o pantallas de ordenador en aplicaciones no basadas en web.
El controlador de diabetes 104 puede comunicarse con el dispositivo móvil 302 usando Bluetooth. El dispositivo móvil 302 puede incluir un teléfono celular, un buscapersonas o un asistente digital personal (PDA). El controlador de diabetes 104 puede enviar datos a una red externa a través del dispositivo móvil 302. El dispositivo móvil 302 puede transmitir mensajes a la red externa tras recibir datos desde el controlador de diabetes 104.
Un controlador de diabetes 104 ilustrativo se describe adicionalmente en relación con la Figura 4. El controlador de diabetes 104 comprende un módulo de medición de glucosa en sangre (BGM) 400, un primer módulo de comunicación 402, un segundo módulo de comunicación 403, un módulo de interfaz de usuario 404, interfaces de usuario 406, un módulo de procesamiento 408, memoria 410 y un módulo de potencia 412. El módulo de interfaz de usuario 404 y el módulo de procesamiento 408 pueden implementarse mediante un módulo de procesamiento de aplicación 409. El módulo de BGM 400 incluye un motor de medición de glucosa en sangre que analiza muestras proporcionadas por el paciente 100 en la tira de medición de glucosa en sangre 306 y que mide la cantidad de glucosa en sangre en las muestras. El primer módulo de comunicación 402 puede incluir múltiples radios que comunican con diferentes dispositivos del sistema de control de diabetes 300. El segundo módulo de comunicación 403 puede incluir puertos para realizar comunicación por cable con dispositivos externos, por ejemplo un ordenador externo. Un puerto ilustrativo es un puerto USB. El módulo de interfaz de usuario 404 interconecta el controlador de diabetes 104 a diversas interfaces de usuario 406 que el paciente 100 puede usar para interactuar con el controlador de diabetes 104. Por ejemplo, las interfaces de usuario 406 puede incluir teclas, conmutadores, un visualizador, un altavoz, un micrófono, un puerto de tarjeta digital segura (SD), etc. (no mostrados).
El módulo de procesamiento 408 procesa datos recibidos desde el módulo de BGM 400, el módulo de comunicación 402 y el módulo de interfaz de usuario 404. El módulo de procesamiento 408 usa la memoria 410 para procesar y almacenar datos. La memoria 410 puede incluir memoria volátil y no volátil. El módulo de procesamiento 408 emite datos a y recibe datos desde las interfaces de usuario 406 a través del módulo de interfaz de usuario 404. El módulo de procesamiento 408 emite datos a y recibe datos desde los dispositivos del sistema de control de diabetes 300 a través del módulo de comunicación 402. El módulo de potencia 412 suministra potencia a los componentes del controlador de diabetes 104. El módulo de potencia 412 puede incluir una batería recargable. La batería puede recargarse usando un adaptador que se conecta en una toma de pared. La batería también puede cargarse a través del puerto USB del controlador de diabetes 104.
Para propósitos de esta divulgación, el controlador de diabetes 104 sirve como un dispositivo de recopilación. Sin embargo, el dispositivo de recopilación puede ser cualquier dispositivo electrónico portátil que puede proporcionar un mecanismo de adquisición para determinar y almacenar medidas psicológicas de una persona. Por ejemplo, medidores de glucosa en sangre de auto supervisión y dispositivos de supervisión de glucosa continuos son ejemplos de dispositivos de recopilación usados en el cuidado de diabetes. Mientras esta divulgación hace referencia al cuidado de diabetes, se entiende fácilmente que los conceptos divulgados en este documento pueden aplicarse a otros tipos de enfermedades crónicas y/o dispositivos de recopilación.
Como se evidencia por la lista de dispositivos que pueden usarse para gestionar dispositivos, es beneficioso habilitar
comunicación entre los dispositivos. En particular, un ordenador que ejecuta una aplicación de control de diabetes y/o una aplicación de gestión de dispositivo se configura para proporcionar datos, firmware, archivos de configuración, instrucciones u otras comunicaciones a dispositivos médicos usados en conexión con el control de diabetes del paciente y para recuperar datos de los dispositivos médicos. Como se analizará en mayor detalle, sin embargo, dispositivos médicos tal como una bomba de insulina o un CGM se configuran únicamente habitualmente para comunicarse con el dispositivo de control de diabetes. Mientras el ordenador puede tener capacidades para comunicarse con diversos dispositivos, el emparejamiento de tales dispositivos con cualquiera y todos los dispositivos de un paciente también puede ser engorroso. Por lo tanto, para efectuar comunicación entre el ordenador y el dispositivo médico, el dispositivo de control de diabetes se configura para soportar comunicación de transferencia. Para habilitar comunicación de transferencia, el dispositivo de control de diabetes actúa como un concentrador entre un dispositivo informático externo y dispositivo médico, por ejemplo una bomba de insulina o un CGM. El dispositivo de control de diabetes recibe un paquete de datos desde uno del dispositivo informático externo y el dispositivo médico y reconfigura y reenvía el paquete de datos al otro del dispositivo informático externo y el dispositivo médico.
Las Figuras 5-7 ilustran realizaciones ilustrativas de un dispositivo de control de diabetes 500, dispositivo informático 600 y un dispositivo médico 600, respectivamente, configurados para realizar comunicación de transferencia. En la Figura 5, se representa un dispositivo de control de diabetes 500 ("controlador de diabetes"). Como se ha analizado con respecto a la Figura 4, un controlador de diabetes 500 ilustrativo incluye un procesador de controlador de diabetes 506, un controlador de diabetes memoria 502, un módulo de glucosa en sangre 504, un primer módulo de comunicación 508 y un segundo módulo de comunicación 510. El controlador de diabetes 500 representado en la Figura 5 incluye adicionalmente un módulo de transferencia 512. El módulo de transferencia se configura para establecer selectivamente una trayectoria de comunicación de transferencia entre el dispositivo informático externo 600 y un dispositivo médico 700. Se observa que en algunos sistemas de control de diabetes, más de un dispositivo médico 700 puede estar en comunicación con el controlador de diabetes 500. Por lo tanto, se habilita cuando comunicación de transferencia, el controlador de diabetes 500 puede recibir en una instrucción de transferencia una designación de un dispositivo médico 700 particular con el que habilitar comunicación de transferencia.
Haciendo referencia ahora a la Figura 6, se representa un dispositivo informático externo 600 ilustrativo. El dispositivo informático externo 600 ilustrativo incluye un procesador de dispositivo informático 606, memoria de dispositivo informático 602 y al menos una de una aplicación de control de diabetes 604 y una aplicación de gestión de dispositivo 610, cualquiera de las cuales se incorpora como instrucciones ejecutables por ordenador que pueden almacenarse en el dispositivo informático memoria 602 y ejecutarse en el procesador de dispositivo informático 606. La aplicación de control de diabetes 604 ilustrativa puede recopilar y almacenar datos relacionados con la diabetes de un paciente y puede generar instrucciones para controlar la diabetes del paciente, por ejemplo, dosis de insulina recomendadas o ingesta de alimento recomendada. Se aprecia que la aplicación de control de diabetes 604 puede realizar también tareas adicionales. La aplicación de gestión de dispositivo 610 ilustrativa puede realizar tareas de gestión de dispositivo para el controlador de diabetes 500 y uno o más dispositivos médicos 700. Por ejemplo, la aplicación de gestión de dispositivo 610 puede determinar qué versión de firmware contiene un dispositivo particular, y si la versión de firmware está anticuada y se requiere una actualización. Además, la aplicación de gestión de dispositivo 610 puede descargar la actualización de firmware y transmitir la actualización de firmware al dispositivo particular. Como puede apreciarse, el dispositivo informático externo 600 necesita comunicarse con el controlador de diabetes 500 de modo que la aplicación de gestión de dispositivo 610 y la aplicación de control de diabetes 604 pueden realizar sus respectivas funciones. Por lo tanto, el dispositivo informático externo utiliza un módulo de comunicación de dispositivo informático 608 para establecer un enlace de comunicación bidireccional con el controlador de diabetes 500. En una realización ilustrativa, el enlace de comunicación es un enlace de comunicación por cable, por ejemplo, un enlace de USB entre el dispositivo informático externo 600 y el controlador de diabetes 500. Se aprecia que el dispositivo informático externo 600 y el controlador de diabetes 500 intercambian paquetes de datos que tienen una estructura predeterminada a través del enlace de comunicación bidireccional. Adicionalmente, en otras realizaciones, se aprecia que la comunicación bidireccional puede ser a través de un enlace inalámbrico, por ejemplo WiFi, WiMax, Bluetooth o similar.
Haciendo referencia ahora a la Figura 7, se representa un dispositivo médico 700 que realiza una tarea relacionada con control de diabetes. Un dispositivo médico 700 ilustrativo puede ser una bomba de insulina, un CGM, un parche de insulina o similar. El dispositivo médico 700 incluye un procesador de dispositivo médico 706 y una memoria de dispositivo médico 702. El dispositivo médico 700 incluye adicionalmente una aplicación de dispositivo médico 704, que se incorpora como instrucciones legibles por ordenador almacenadas en la memoria de dispositivo médico 702 y ejecutables por el procesador de dispositivo médico 706. La aplicación dispositivo médico 704 es una aplicación relacionada con la realización de la tarea relacionada con el control de diabetes. Por ejemplo, en el caso de una bomba de insulina, la aplicación de control de diabetes 704 puede ser una aplicación para medir cantidades particulares de insulina o para actualizar el firmware de la bomba de insulina. El dispositivo médico 700 incluye adicionalmente un módulo de comunicación 708 de dispositivo médico 700 para establecer un enlace de comunicación con el controlador de diabetes 500. En una realización ilustrativa, el enlace de comunicación en el que el dispositivo médico 700 comunica con el controlador de diabetes 500 es un enlace de comunicación bidireccional inalámbrico, por ejemplo Bluetooth, IR, Zigbee, Wifi o similar. Se aprecia que el dispositivo médico 700 y el controlador de diabetes 500 intercambian paquetes de datos que tienen una estructura predeterminada a través del enlace de comunicación bidireccional.
La Figura 8 ilustra un ejemplo de un sistema de control de diabetes 800 que tiene habilitada comunicación de
transferencia. Como se ha analizado, el controlador de diabetes 500 puede configurarse para comunicarse con un ordenador externo 600 y uno o más dispositivos médicos, por ejemplo una bomba de insulina, un CGM, un parche de insulina o similar. El controlador de diabetes 500 comunica con el dispositivo informático externo 600 a través de un primer enlace de comunicación entre el primer módulo de comunicación 508 del controlador de diabetes 500 y el módulo de comunicación de dispositivo informático 608 del dispositivo informático externo 600. El controlador de diabetes 500 comunica con el dispositivo médico 700 a través de un segundo enlace de comunicación entre el segundo módulo de comunicación 510 del controlador de diabetes 500 y el módulo de comunicación de dispositivo médico 708 del dispositivo médico. Un módulo de transferencia 512 ilustrativo se configura para recibir, desde el dispositivo informático externo 600, una instrucción que designa un dispositivo médico 700 particular con el que establecer comunicación de transferencia. Como se ha mencionado, el dispositivo médico 700 designado puede seleccionarse de una pluralidad de dispositivos médicos disponibles. El módulo de transferencia 512 recibe la instrucción y establece una trayectoria de comunicación de transferencia entre el dispositivo médico 700 particular y el dispositivo informático externo 500.
Una vez que se ha establecido la trayectoria de comunicación de transferencia, puede comenzar la comunicación de transferencia y se transfieren datos automáticamente entre el dispositivo informático externo 600 y el dispositivo médico 700. Comunicación de transferencia permite que el dispositivo informático externo 600 transmita mensajes al dispositivo médico 700 y el dispositivo médico 700 transmita mensajes al dispositivo informático externo 600, a pesar de que no existe ningún enlace de comunicación directo entre los dos dispositivos 600 y 700. Para facilitar comunicación eficiente entre el dispositivo informático externo 600 y el dispositivo médico 700, el módulo de transferencia 512 recibe primeros paquetes de datos desde el dispositivo informático externo a través del primer enlace de comunicaciones bidireccional. Los primeros paquetes de datos pueden incluir una instrucción de transferencia y unos datos de carga útil de transferencia. Los primeros paquetes de datos tendrán una estructura que corresponde al protocolo de comunicación usado para transmitir el paquete de datos a través del primer enlace de comunicaciones bidireccional. Por ejemplo, un paquete de datos de USB puede tener un dispositivo de interfaz física (PID) seguido por una cantidad predeterminada de bytes de datos de carga útil y una comprobación de redundancia cíclica de 16 bits. El módulo de transferencia 512 convierte los primeros paquetes de datos en segundos paquetes de datos. El segundo paquete de datos incluye los datos de carga útil de transferencia. El segundo paquete de datos tendrá una estructura que corresponde al protocolo de comunicación usado para transmitir el segundo paquete de datos a través del segundo enlace de comunicación bidireccional. Por ejemplo, un paquete de datos por Bluetooth ilustrativo puede tener un código de acceso, seguido por un encabezamiento, seguido por una carga útil que tiene una longitud predeterminada. Una vez que el primer paquete de datos se convierte a un segundo paquete de datos, es decir, se ha generado un segundo paquete de datos que contiene los datos de carga útil del primer paquete de datos, el módulo de transferencia transmite los segundos paquetes de datos al dispositivo médico 700 a través del segundo enlace de comunicaciones bidireccional.
En respuesta a recibir satisfactoriamente los datos de carga útil de transferencia, el dispositivo médico 700 puede confirmar la recepción al dispositivo de control de diabetes 500, que a su vez puede confirmar la recepción al dispositivo informático externo 600.
De manera similar, una vez que se establece la trayectoria de comunicación de transferencia, el dispositivo médico 700 puede transmitir datos al dispositivo informático externo 600 a través de la trayectoria de comunicación de transferencia. El dispositivo médico 700 transmitirá un tercer paquete de datos de la segunda estructura de paquete de datos al segundo módulo de comunicación 510 del controlador de diabetes 500. El módulo de transferencia 512 recibirá el tercer paquete de datos, incluyendo una instrucción de transferencia y una carga útil, y convertirá el tercero en un cuarto paquete de datos de la primera estructura de paquete de datos que incluye la carga útil. El módulo de transferencia 512 transmitirá a continuación el cuarto paquete de datos al dispositivo informático externo 600 a través del primer enlace de comunicación.
El módulo de transferencia 512 también puede recibir a una instrucción de deshabilitar comunicación de transferencia para deshabilitar la comunicación de transferencia. Cuando se recibe una instrucción de deshabilitar comunicación de transferencia, el módulo de transferencia 512 terminará la trayectoria de comunicación de transferencia entre el dispositivo informático externo 600 y el dispositivo médico 700. Por lo tanto, una vez que el módulo de transferencia está operando en un modo de transferencia, cada vez que el módulo de transferencia 512 recibe una instrucción el módulo de transferencia 512 comprobará el paquete de datos para determinar si la instrucción es una instrucción de transferencia o una instrucción de deshabilitar comunicación de transferencia. Si la instrucción es del primer tipo, el módulo de transferencia 512 convertirá el paquete de datos al tipo de paquete de datos apropiado y transmitirá el paquete convertido al dispositivo apropiado. Si, sin embargo, la instrucción es una instrucción de deshabilitar transferencia, el módulo de transferencia 512 deshabilitará la trayectoria de comunicación de transferencia.
Configurando el controlador de diabetes 500 para realizar comunicación de transferencia, puede producirse comunicación eficiente entre el dispositivo informático externo 600 y el dispositivo médico 700. Por ejemplo, si necesita actualizarse el firmware de una bomba de insulina o CGM, la aplicación de gestión de dispositivo que se ejecuta en el dispositivo informático externo 600 puede transmitir una instrucción de habilitar comunicación de transferencia al controlador de diabetes 500. Una vez que una trayectoria de comunicación de transferencia se establece, la actualización de firmware puede transmitirse a la bomba de insulina a través de la trayectoria de comunicación de
transferencia. De manera similar, si la aplicación de control de diabetes requiere datos desde un CGM o bomba de insulina, puede hacerse una petición para obtener datos de la misma, y los datos se transmiten al dispositivo informático externo 600 desde el dispositivo médico 700 a través de la trayectoria de comunicación. Adicionalmente, el modo de comunicación de transferencia puede permitir que un médico tratante configure un dispositivo médico 700 de un paciente sin emparejar realmente al dispositivo médico 700 del paciente. En su lugar, pueden transmitirse parámetros de configuración al dispositivo médico 700 desde el dispositivo informático externo 600 del médico a través de la trayectoria de comunicación de transferencia.
Como se ha analizado, el controlador de diabetes 500 es capaz de comunicarse con diversos dispositivos. Para facilitar comunicaciones eficientes entre el dispositivo informático externo 600 o uno o más dispositivos médicos 700, comunicaciones entre dispositivos cumplen con ISO/IEEE 11073. ISO/IEEE 11073 es la norma de comunicación de dispositivos médicos y de salud, que habilita la comunicación entre dispositivos médicos y dispositivos informáticos externos. La norma ISO/IEEE 11073 proporciona interoperabilidad de enchufar y usar entre dispositivos médicos y/o dispositivos informáticos externos. Además, la norma ISO/IEEE 11073 proporciona intercambio eficiente de datos recopilados en el punto de atención entre dispositivos. El resultado es que datos de punto de atención pueden recuperarse, archivarse y analizarse sin el requisito de software extensivo para soportar el intercambio de datos entre dispositivos. Adicionalmente, ISO/IEEE 11073-20601 define un marco común para hacer un modelo abstracto de datos de salud personales disponibles en sintaxis de transferencia independiente del transporte requerida para establecer conexiones lógicas entre sistemas y para proporcionar capacidades de presentación y servicios necesarios para realizar tareas de comunicación. El protocolo se optimiza para requisitos de uso de salud personal y aprovecha los métodos y herramientas usados comúnmente siempre que es posible. En el caso de medidas de glucosa en sangre, el controlador de diabetes 500 puede implementar un protocolo de comunicación especializado dispositivo de según se define mediante la norma de IEEE 11073-10417. Para otros tipos de medidas, se entiende que el controlador de diabetes 500 puede implementar el protocolo de comunicación especializado aplicable.
Como se ha analizado, la norma ISO/IEEE 11073 habilita comunicación entre dispositivos médicos y otros sistemas informáticos. Por medio de antecedentes, la norma ISO/IEEE 11073 se basa en un paradigma de gestión de sistemas orientados a objeto. El modelo de sistema general se divide en tres componentes principales: el modelo de información de dominio (DIM), el modelo de servicio, y el modelo de comunicación. Estos tres componentes trabajan juntos para representar datos, definir acceso de datos y ordenar metodologías y comunican los datos desde un agente a un gestor. Puede hacerse referencia a ISO/IEEE 11073-20601 para una descripción detallada de las construcciones de modelo aunque cada uno se describe brevemente a continuación.
El modelo de información de dominio es un modelo jerárquico que describe un agente como un conjunto de objetos. Estos objetos y sus atributos representan los elementos que controlan comportamiento y notifican sobre el estado del agente y los datos que un agente puede comunicar a un gestor. Con referencia a la Figura 11, se define un diagrama de clases para un dispositivo de salud personal de acuerdo con ISO/IEEE 11073-20601. La clase de Sistema de Dispositivo Médico (MDS) 1102 es la clase raíz del dispositivo y contiene atributos que definen al propio dispositivo. Atributos ilustrativos incluyen el tipo de dispositivo, es decir, medidor de glucosa o bomba de insulina, información de fabricante y modelo e información de certificación registrada. Todas las demás clases de objeto se derivan a partir de la clase de MDS. Por ejemplo, la clase Numérica representa mediciones numéricas tal como bG, carbohidratos, cantidad de bolo, etc.; mientras que, la clase de enumeración representa información de estado y/o información de anotación. Por propósitos de brevedad, no se proporciona una descripción para todas las clases mostradas en la figura.
La comunicación entre el agente y el gestor se define mediante el protocolo de aplicación en ISO/IEEE 11073-20601. El modelo de servicio define los mecanismos conceptuales para los servicios de intercambio de datos. Servicios de acceso de objeto, tal como Get, Set, Action y Event Reports, se correlacionan con mensajes que se intercambian entre el agente y el gestor. Mensajes de protocolo dentro de la serie de normas ISO/IEEE 11072 se definen en ASN. 1. Los mensajes definidos en ISO/IEEE 11073-20601 pueden coexistir con mensajes definidos en otros perfiles de aplicación de normar definidos en la serie de normas ISO/IEEE 11072.
En general, el modelo de comunicación soporta la topología de uno o más agentes que se comunican a través de conexiones lógicas punto a punto a un único gestor. Más específicamente, el modelo de comunicación define la construcción de una unidad de datos de protocolo de aplicación (APDU). Las ADPU son paquetes de datos intercambiados entre agentes y gestores. Para cada conexión lógica punto a punto, el comportamiento de sistema dinámico se define mediante una máquina de estados de conexión como se especifica en ISO/IEEE 11073-20601.
En ISO/IEEE 11073-20601 se definen dos estilos de configuración: normal y extendida. Las configuraciones estándar se definen en las especializaciones ISO/IEEE 11073-104zz (tal como la especialización de Dispositivo de Glucosa en ISO/IEEE 11073-10417) y se asignan un identificador bien conocido (Dev-Configuration-Id). El uso de una configuración estándar se negocia en momento de asociación el agente y el gestor. Si el gestor conforma que entiende y quiere operar usando la configuración, a continuación el agente puede empezar a enviar mediciones inmediatamente. Si el gestor no entiende la configuración, el agente proporciona la configuración antes de transmitir la información de medición.
En las configuraciones extendidas, la configuración del agente no se predefine en una norma. El agente determina qué objetos, atributos y valores se usarán en una configuración y asigna un identificador de configuración. Cuando el agente se asocia con un gestor, negocia una configuración aceptable. Típicamente, el gestor no reconoce la configuración del agente en la primera conexión, de forma que el gestor responde que el agente necesita enviar la información de configuración como un informe de evento de configuración. Si, sin embargo, el gestor ya entiende la configuración, o bien porque se precargó de alguna forma o bien el agente se había asociado anteriormente con el gestor, a continuación el gestor responde que la configuración se conoce y no necesita enviarse información de configuración adicional.
Con referencia a la Figura 9, esta divulgación define una extensión 902 a estas configuraciones, es decir, extensión privada del solicitante, que no se publica en ninguna de las especializaciones 904 de dispositivos de ISO/IEEE 11073-104xx. La relación de extensión privada del solicitante 902 con los protocolos de comunicación normalizados se muestra en la Figura 9. Hablando en general, la implementación de esta extensión privada 902 define los atributos y servicios para soportar la transferencia y ejecución de instrucciones y datos específicos. A continuación se describe primero un marco básico para la extensión privada. Dentro de este marco, se presentan a continuación mediante esta divulgación un conjunto de instrucciones de transferencia para establecer una trayectoria de comunicación de transferencia y habilitar comunicación entre un dispositivo informático externo 600 y un dispositivo médico 700. El conjunto de instrucciones para comunicación de transferencia se usa por el dispositivo informático externo 600 y el dispositivo médico 700 para comunicación entre sí a pesar de que no hay trayectoria de comunicación directa entre ellos. Además, como resultado de la comunicación de transferencia, acción tal como actualización de firmware e I/O de archivo puede realizarse entre el dispositivo informático externo 600 y el dispositivo médico 700. También se divulgan en este documento instrucciones ilustrativas para actualización de firmware e I/O de archivo. Se entiende fácilmente que otros tipos de conjuntos de instrucciones también pueden encontrarse dentro del marco para la extensión privada.
En una realización ilustrativa de extensión privada del solicitante, cada dispositivo de agente tiene un objeto de MDS. Este objeto de MDS de nivel superior se instancia a partir de la clase de MDS. El objeto de MDS representa la identificación y estado del agente a través de sus atributos. Más allá de la definición de clase proporcionada por las normas de IEEE, pueden soportarse clases normalizadas adicionales por los agentes y gestores de acuerdo con extensión privada del solicitante. Las clases normalizadas adicionales se denominan en este documento como clases de RPC. Los códigos de nomenclatura privada de RPC se asignan a partir de un intervalo específico del fabricante de códigos de términos privados (0xF000 - OxFBFF) dentro de la categoría de partición orientada a objeto (MDC_PART-OBJ). El número de división para clases y objetos orientados a objeto es 1.
Los atributos para cada clase de RPC se definen en tablas que especifican el nombre del atributo, su valor y su calificador. Los calificadores significan M - atributo es obligatorio, C - atributo es condicional y depende de la condición indicada en la columna de observación o valor, R - atributo recomendado, NR - atributo no recomendado, y O - atributo es opcional. Los atributos obligatorios se implementarán por un agente. Los atributos condicionales se implementarán si la condición es aplicable y puede implementarse de otra manera. Los atributos recomendados deberían implementarse por el agente.
Los atributos no recomendados no deberían implementarse por el agente. Los atributos opcionales pueden implementarse en un agente.
Las clases de RPC que instancien objetos de tipo numérico se crean tal como existen en el dispositivo. Estos objetos de tipo numérico representan datos de resultados adicionales que pueden obtenerse a partir del dispositivo de la misma manera se obtienen a partir de la especialización de dispositivo. Estos objetos se añadirán al mapa de valores de atributos de dispositivo para gestores autenticados. Atributos comunes a través de todos los objetos numéricos de RPC se exponen en el Anexo A. Adicionalmente, extensión privada del solicitante ha definido unos pocos objetos numéricos de RPC disponibles para diseñadores de sistema. Análogamente, definiciones para estos objetos numéricos de RPC comunes se exponen en el Anexo A.
Extensión privada del solicitante adicionalmente define una unidad de datos de protocolo de aplicación como se expone a continuación. Una APDU representa el marco de mensaje de nivel superior del protocolo de dispositivo de salud personal. La APDU extendida se añade como una extensión a la lista estándar de APDU definidas en la especificación ISO/IEEE 11073-20601.
Apdu Type ::==CHOICE {
aarg [57856] AarqApdu, -- Petición de Asociación [0xE200] aare [58112] AareApdu, -- Respuesta de Asociación [0xE300] rlrq [58368] RlrqApdu, -- Petición de Publicación de Asociación [0xE400] rlre [58624] RlreApdu, -- Respuesta de Publicación de Asociación [0xE500] abrt [58880] AbrtApdu, -- Cancelar Asociación [0xE600] prst [59136] PrstApdu, -- APDU de Presentación [0xE700] prrp [61440] PrrpApdu - APDU extendida del solicitante [0xF000] }
Una APDU de presentación como se define en ISO/IEEE 11073-20601 es simplemente una cadena de octetos. La APDU extendida del solicitante añade una CRC de 16 bits para garantizar la integridad de datos más allá del nivel proporcionado por el transporte y el concepto de ISO/IEEE 11073-20601 de canales de datos fiables. Con esta CRC, la aplicación puede detectar datos corrompidos. Esta CRC cubre toda la parte de "RPC" de las APDU de instrucción de invocar e instrucción de responder.
PrrpApdup ::= SEQUENCE {
data OCTET STRING, (VERSIÓN CODIFICADA de DataApdu)
crc INT-U16 (suma de comprobación en todo el campo de datos)
}
APDU extendida del solicitante encapsulará APDU de argumento de acción no confirmación y de informe de evento confirmado definidas por la norma ISO/IEEE 11073-20601 como se indica a continuación:
ActionArgumentSimple ::= SEQUENCE {
obj-handle HANDLE
action-type OID-Type, --De la partición de nom-part-obj
— Subpartición ACT (MDC_ACT_*)
Action-info-args ANY DEFINED BY action-type
}
EventReportArgumentSimple ::=SEQUENCE {
obj-handle HANDLE event-time Relative Time,
event-type OID-Type --De la partición nom-part-obj
— Subpartición NOTI (MDC_NOTI_*)
event-info ANY DEFINED BY event-type
El enfoque usado para invocar las instrucciones definidas por el solicitante es para extender los métodos de objeto de MDS con acciones definidas por solicitante. El servicio de acción no confirmado de ISO/IEEE 11073-20601 usa la estructura ActionArgumentSimple descrita anteriormente.
Para los propósitos de esta memoria descriptiva, los campos tendrían los siguientes valores:
handle 0 (para el objeto de MDS)
código específico del fabricante para acciones definidas por
action-type solicitante
action-info-args estructura específica de fabricante para cada acción definida
por solicitante
Para invocar una instrucción definida por solicitante, un gestor ocupará los action-type y action-info-arts del objeto ActionArgumentSimple como se indica a continuación:
action-type MDC_ACT_RPC_COMMAND_INVOKE
action-info-args RpcCommandArguments
Los objetos de datos usados para invocación de action-info-args se definen como se indica a continuación:
RpcCommandArguments ::= SEQUENCE {
cmd-subcmd INT-U16; //Argumentos de instrucción/subinstrucción combinados
arguments RpcDataArguments [ ];
}
RpcDataArguments ::= SEQUENCE {
type INT-U16;
data ANY DEFINED BY type
}
La codificación de ANY DEFINED BY se define en ISO/IEEE 11073-20601 como se indica a continuación: El tipo de ANY DEFINED BY (ASN.1 1988/90) o el tipo de instance-of (ASN.1 1994) se codifica mediante un encabezamiento de un campo de longitud para especificar el número de octetos en la codificación del valor seleccionado que sigue. El elemento de longitud se expresará como el número de bytes (octetos) contenidos en el elemento de valor. Un argumento vacío se indicará con el elemento de tipo establecido a RPC_ARG_TYPE_EMPTY, el elemento de longitud establecido a 2 y el elemento de valor establecido a cero como un INT-U16. Una estructura de RpcCommandArguments que contiene un valor de cmd-subcmd que no requiere ningún argumento incluirá un único
elemento de RpcDataArguments que indica un argumento vacío.
El enfoque usado para devolver datos como resultado de una invocación de instrucción definida por de solicitante es para extender los informes de evento de MDS con eventos definidos por solicitante. El servicio de notificación confirmado de ISO/IEEE 11073-20601 usa la estructura EventReportArgumentSimple analizada anteriormente en esta divulgación. Para los fines de la memoria descriptiva, los campos tendrán los siguientes valores:
Handle 0 (para el objeto de MDS)
event-time 0 (tiempo de evento no se usa para acciones de
solicitante)
event-type código específico del fabricante para respuestas de
instrucción definida por solicitante. -event-info estructura específica del fabricante para cada
respuesta definida por solicitante.
Para responder a una instrucción definida por solicitante, un agente ocupará el event-type y event-info del objeto de EventReportArgumentSimple como se indica a continuación:
Event-type MDC_NOTI_RPC_COMMAND_RESPONSE
event-info RpcDataArguments [ ]
El objeto de RpcDataArguments es el mismo como se define para acciones definidas por solicitante.
Métodos (acciones) disponibles parar el objeto de MDS se definen en la tabla a continuación. Estos métodos se invocan usando el servicio de ACTION. En la tabla, la columna de método/acción define el nombre del método. La columna de modo define si el método se invoca como una acción no confirmada (es decir, roiv-cmip-action) o una acción confirmada (es decir, roiv-cmip-confirmed-action). La columna de Action-type define el ID de nomenclatura a usar en el campo de action-type de una solicitud de acción y respuesta. La columna de action-info-args define la estructura de datos asociada para usar en el mensaje de acción para el campo de action-info-args de la petición. La columna de Action-info-args resultante define la estructura para usar en el action-info-args de la respuesta.
Este método permite que el gestor invoque una instrucción de sistema definida por solicitante.
Eventos potenciales enviados por el objeto de RPC se definen en la tabla a continuación. Un gestor soportará todos métodos definidos en la tabla.
Para el evento de respuesta de instrucción, después de que la ejecución de una instrucción definida por solicitante se ha solicitado a través del servicio de ACTION, el agente procesará los objetos de instrucción, subinstrucción y parámetro. Si no hay errores de parámetros de instrucción, el resultado será un informe de evento iniciado por agente que reflejará el resultado de procesamiento de instrucción satisfactorio. En el caso de éxito de instrucción, el informe de evento contendrá una cadena de datos de resultados específicos de la instrucción según se define mediante esta memoria descriptiva.
Para el evento de respuesta de error, después de que se ha solicitado una instrucción definida por solicitante a través del servicio de ACTION, el agente procesará los objetos de instrucción, subinstrucción y parámetro. Si hay errores de parámetro, el resultado será un informe de evento iniciado por agente que especifica el error de parámetro. Si un gestor recibe una respuesta de RPC_ERR_HARDWARE o Rp C_ERR_Ap PLiCa TION, el gestor debería invocar la instrucción de leer y borrar estado de RPC para recuperar adicionalmente información de error disponible del dispositivo.
Dentro de este marco, a continuación se describe adicionalmente un conjunto de instrucciones que soportan comunicación de transferencia. Las comunicaciones con dispositivos externos conectados al dispositivo se logran usando la instrucción de modo de transferencia en conjunto con las subinstrucciones analizadas en este documento. En una realización ilustrativa, la instrucción para realizar modo de transferencia es RPC_CMD_PASS_THRU_MODE y tiene un valor de 0x8700. El valor de la instrucción de transferencia puede ser "OR-ed" con un de los valores de
subinstrucción de actualización de firmware, analizados a continuación, para formar un valor de instrucciónsubinstrucción completo. Como se ha analizado, pueden usarse comunicaciones modo de transferencia con únicamente un dispositivo a la vez. Por lo tanto, cuando se desea un modo de transferencia, se emite una instrucción de habilitar modo de transferencia para habilitar modo de transferencia. La instrucción de habilitar modo de transferencia ordena al controlador de diabetes 500 que habilite comunicaciones de transferencia con el dispositivo médico 700 designado. El parámetro de entrada es un valor de component-id que se obtiene emitiendo primero una "Leer información de dispositivo externo". La instrucción de leer información de dispositivo externo devuelve un código de error que indica éxito (RPC_ERR_NO_ERRORS) o fracaso. Si el dispositivo médico designado no existe, el controlador de diabetes 50 devuelve un mensaje de error, por ejemplo RPC_ERR_APPLICATION_ERROR. Una definición ilustrativa de instrucción de habilitar transferencia y una respuesta a la misma se definen como se indica a continuación:
Instrucción/Subinstrucción= 0x8701
Parámetros de entrada:
Dispositivo de transferencia PrivateOid (UINT16)
Parámetros de salida:
Código de error Número
Invocación de instrucción de RPC:
Res uesta de instrucción de RPC:
Una vez que se emite una habilitar instrucción de transferencia, y el controlador de dispositivo 500 habilita satisfactoriamente modo de transferencia, es decir, establece una trayectoria de comunicación de transferencia entre el dispositivo informático externo 600 y el dispositivo médico 700 designado, el dispositivo informático externo 600 y el dispositivo médico 700 designado pueden comunicarse en modo de transferencia emitiendo instrucciones de transferencia. Como se ha analizado anteriormente, una instrucción de transferencia ordena al controlador de diabetes 500 que transmita datos de carga útil al dispositivo médico 700 o dispositivo informático externo 600 habilitado para transferencia en la actualidad. La instrucción de transferencia incluye al menos un parámetro de entrada. En una realización ilustrativa, el parámetro de entrada es la carga útil a suministrar al dispositivo de transferencia 700 o 500 como una matriz de bytes, por ejemplo RPC_ARG_TYPE_UINT8_ARRAY. La instrucción de transferencia devuelve un código de error que indica transmisión satisfactoria de la carga útil al dispositivo de transferencia, por ejemplo RPC_ERR_NO_ERRORS, o fallo, como se muestra en el Anexo B. Si en la actualidad no hay dispositivo de transferencia habilitado, el dispositivo devolverá un RPC_ERR_APPLICATION _ERROR. Lo siguiente ilustra una definición ilustrativa de una instrucción de transferencia y una respuesta a la misma:
Instrucción/Subinstrucción= 0x8703
Parámetros de entrada:
Datos de carga útil de Tx [] Matriz UINT8
Parámetros de salida:
Respuesta de error de instrucción (si la carga útil no puede transmitirse)
Código de error Número
Informe de evento de datos de carga (si no hay errores a notificar)
Datos de carga útil de Rx Matriz UINT 8.
Invocación de instrucción de RPC:
T ras recibir la invocación de instrucción, el controlador de diabetes 500 envía o bien un informe de evento de respuesta de error de instrucción o bien uno o más informes de evento de datos de carga útil de Rx que contienen datos de carga útil del dispositivo de transferencia. El dispositivo de agente enviará la respuesta de error de instrucción si los datos de carga útil de Tx no pueden enviarse al dispositivo de transferencia. Si no hay errores a notificar, el dispositivo de agente comenzará a enviar informes de evento de datos de carga útil de Rx a medida que se reciben cargas útiles desde el dispositivo de transferencia. La siguiente tabla ilustra respuestas de error de instrucción ilustrativas:
Res uesta de error de instrucción de RPC:
Cuando se habilita modo de transferencia para comunicaciones con un dispositivo de transferencia, cualquier carga útil de transmisión recibida por el dispositivo de agente se reenviará al gestor usando un informe de evento de MDC_NOTI_RPC_PASSTHRU_DATA. El argumento del informe de evento son los datos de carga útil recibidos como una matriz de bytes (RPC_ARG_TYPE_UINT8_ARRAY). No hay respuesta de gestor a este informe de evento. La siguiente es una tabla ilustrativa que indica un informe de evento de transferencia:
Informe de evento de datos de transferencia de RPC:
Cuando se completa comunicación entre el dispositivo informático externo 600 y el dispositivo médico 700 designado, uno de los dispositivos, normalmente el dispositivo informático externo 600, emitirá una instrucción de deshabilitar transferencia que indica que la trayectoria de comunicación de transferencia tiene que deshabilitarse. La instrucción de deshabilitar transferencia ordena al controlador de diabetes 500 que deshabilite comunicaciones de transferencia con el dispositivo habilitado en la actualidad. La instrucción devuelve un código de error que indica éxito (RPC_ERR_NO_ERRORS) o fallo. Véase el Anexo B para enumeraciones de código de error. Si no hay dispositivo de transferencia habilitado en la actualidad, el dispositivo devolverá un RPC_ERR_APPLICATION_ERROR. Una definición ilustrativa es una instrucción de deshabilitar transferencia se define como se indica a continuación:
Instrucción/Subinstrucción= 0x8702
Parámetros de entrada:
Ninguno
Parámetros de salida:
Código de error Número
Invocación de instrucción de RPC:
es uesta e nstrucc n e :
Lo anterior ilustra un conjunto ilustrativo de instrucciones de transferencia para establecer una trayectoria de comunicación de transferencia y habilitar comunicación entre el dispositivo informático externo y el primer dispositivo médico. Se observa que el conjunto de instrucciones de transferencia se define de conformidad con un protocolo de comunicación definido de acuerdo con la norma de IEEE 11073-20601.
Como se ha analizado, cuando en modo de transferencia, el controlador de diabetes 500 puede usarse como un concentrador de comunicación para realizar tales tareas como actualizaciones de firmware. El conjunto de instrucciones para realizar actualizaciones de firmware se define también con respecto a la norma de IEEE 11073. Actualizaciones de firmware se logran usando la instrucción de actualización de firmware en conjunto con las subinstrucciones definidas a continuación. La instrucción ilustrativa para realizar actualización de firmware es RPC_CMD_FIRMWARE_UPGRADE y tiene un valor de 0x8500. Debe ser "OR-ed" con uno de los valores de subinstrucción de actualización de firmware para formar un valor de instrucción-subinstrucción completo. Se recomienda que el dispositivo esté en modo de actualización de firmware antes de que se efectúe cualquier transferencia de archivos relacionada con la actualización, de modo que el dispositivo de agente puede asociar estos archivos con el proceso de actualización.
Típicamente, antes de que una actualización de firmware se realiza en un dispositivo médico 700, se lee el estado del firmware del dispositivo médico 700. El estado puede obtenerse de un dispositivo médico 700 emitiendo una instrucción de leer estado de actualización de firmware. La instrucción de leer estado de actualización de firmware ordena al dispositivo a actualizarse que devuelva un número entero sin signo de 16 bits (FwUpgradeStatus) que puede contener banderas de bit que indican la siguiente información de estado:
1. Estado de características de actualización de firmware (upgrade-feature-enabled)
2. Estado capaz de actualización (capable-of-upgrade)
3. Estado de actualización en progreso (upgrade-in-progress)
4. Estado de carga (battery-is-charging)
5. Estado de dispositivo ocupado (device-is-busy)
La siguiente es una definición ilustrativa de una leer estado de actualización de firmware y una respuesta a la misma: Instrucción/Subinstrucción= 0x8501
Parámetros de entrada:
Ninguno
Parámetros de salida:
Banderas de estado de actualización FwUpgradeStatus
Invocación de instrucción de RPC:
Res uesta de instrucción de RPC:
Si el gestor no ha autenticado a la función de actualización de firmware, el dispositivo devuelve un error de aplicación.
Correlación de estado de actualización de firmware con la estructura de FwU radeStatus:
Cuando el dispositivo informático externo 600 u otro dispositivo determina que el dispositivo a actualizar requiere una actualización de firmware, se emite una instrucción de entrar en modo de actualización de firmware. La instrucción de entrar en modo de actualización de firmware ordena al dispositivo a actualizar que entre en modo de actualización de firmware. La instrucción devuelve un código de error que indica éxito, por ejemplo RPC_ERR_NO_ERRORS, o fallo, por ejemplo RPC_ERR_APPLICATION_ERROR. Se observa que en el evento de fallo, el gestor debería comprobar que la característica de actualización de firmware está habilitada en el dispositivo a actualizar, usando la instrucción de "leer estado de actualización de firmware" analizada anteriormente. Cuando el dispositivo a actualizar recibe esta instrucción y no está ya en modo de actualización de firmware, el dispositivo a actualizar debería realizar tareas preparatorias para la actualización, que podría incluir borrar archivos o finalizar comunicaciones con dispositivos externos. En caso de que el dispositivo a actualizar ya esté en modo de actualización de firmware el dispositivo no debería reiniciar el modo de actualización de firmware, sino que en su lugar simplemente devuelve la respuesta de RPC_ERR_NO_ERRORS. Una definición ilustrativa de una instrucción de entrar en modo de actualización de firmware y una respuesta a la misma se definen como se indica a continuación:
Instrucción/Subinstrucción= 0x8502
Parámetros de entrada:
Ninguno
Parámetros de salida:
Código de error Número
Invocación de instrucción de RPC:
continuación
Res uesta de instrucción de RPC:
Una vez que el dispositivo a actualizar ha entrado en el modo de actualización, se emite una instrucción de aplicar actualización de firmware. La instrucción de aplicar actualización de firmware ordena al dispositivo que aplique la actualización de firmware de acuerdo con los procedimientos definidos por las especificaciones del dispositivo. La instrucción devuelve un código de error que indica éxito (RPC_ERR_NO_ERRORS) o
RPC_ERR_APPLICATION_ERROR en el evento de fallo. En caso de que el dispositivo a actualizar no esté en modo de actualización de firmware, el dispositivo a actualizar debería devolver una respuesta de error de aplicación. La siguiente es una definición ilustrativa de una instrucción de aplicar actualización de firmware y una respuesta a la misma:
Instrucción/Subinstrucción= 0x8504
Parámetros de entrada:
Ninguno Parámetros de salida:
Código de error Número
Invocación de instrucción de RPC:
Res uesta de instrucción de RPC:
Una vez que la actualización de firmware se completa, se emite una instrucción de salir de modo de actualización de firmware. La instrucción de salir de actualización de firmware ordenará al dispositivo que salda del modo de actualización de firmware. La instrucción devuelve un código de error que indica éxito (RPC_ERR_NO_ERRORS) o RPC_ERR_APPLICATION_ERROR en el evento de fallo. En caso de que el dispositivo a actualizar no esté en modo de actualización de firmware, el dispositivo debería simplemente devolver la respuesta de RPC_ERR_NO_ERRORS. La siguiente es una definición ilustrativa de una instrucción de salir de modo de actualización de firmware y una respuesta a la misma:
Instrucción/Subinstrucción= 0x8503
Parámetros de entrada:
Ninguno
Parámetros de salida:
Código de error Número
Invocación de instrucción de RPC:
continuación
Res uesta de instrucción de RPC:
Además, el dispositivo informático 600 incluye un conjunto de instrucciones de entrada/salida de archivos ("I/O de archivos") definidas de acuerdo con el protocolo de comunicación definido de acuerdo con la norma ICC-11073. Estas instrucciones se dirigen para realizar operaciones relacionadas con el sistema de archivos del sistema de control de diabetes 500. Instrucciones ilustrativas incluyen instrucciones para leer un archivo, escribir un archivo, cancelar operaciones de leer o escribir y leer un directorio de archivos.
Una instrucción ilustrativa para realizar I/O de archivos es RPC_CMD_FILE_IO y tiene un valor ilustrativo de 0x8200. La instrucción ilustrativa es "OR-ed" con uno de los valores de subinstrucción de I/O de archivos para formar un valor de instrucción-subinstrucción completo. Instrucciones ilustrativas y sus respectivos valores de subinstrucciones se analizan en mayor detalle a continuación.
Como una cuestión de umbral, en una realización ilustrativa archivos transferidos desde un gestor a un agente pueden firmarse digitalmente. La firma digital puede generarse en de cualquier manera conocida consistente con la norma IEEE-11073. Los niveles de seguridad asociados con diferentes tipos de archivo se especificarán mediante las firmas digitales.
Los siguiente describe subinstrucciones ilustrativas dentro del campo de I/O de archivos. Se aprecia que en las siguientes subinstrucciones, el parámetro de nombre de archivo puede incluir información de nombre de volumen y nombre de trayectoria además del nombre real del archivo.
Una primera instrucción de I/O de archivos es una instrucción de leer archivo, que ordena a un dispositivo que devuelta contenidos del archivo especificado en la instrucción como uno o más informes de evento de datos de archivo. En una realización ilustrativa, los eventos de datos de archivo suministran los contenidos del archivo de forma secuencial. Se aprecia que en otras realizaciones los contenidos del archivo pueden suministrarse al dispositivo solicitante de forma no secuencial. El tamaño de APDU sucesivas de informe de evento de datos de archivo es igual al valor devuelto por la instrucción de RPC_CMD_OPERATIONAL_INFO | RPC_SUBCMD_ MAX_APDU_SIZE excepto por la última APDU de informe de evento, que tendrá una longitud que es menor que o igual al valor de tamaño de APDU máximo. Lo siguiente es un ejemplo de la instrucción de leer archivo y una respuesta a la misma. Obsérvese que el valor de la instrucción/subinstrucción es el valor ORed de la instrucción de I/O de archivos y el valor de subinstrucción de leer archivo.
Instrucción/Subinstrucción= 0x8201
Parámetros de entrada:
Nombre de archivo Cadena
Parámetros de salida:
Respuesta de error de instrucción (si no existe archivo o está corrompido)
Código de error Número
Informes de evento de datos de archivo (si no hay archivos a notificar)
Datos de archivo Matriz UINT 8.
Invocación de instrucción de RPC:
Tras recibir la invocación de instrucción, el dispositivo que recibe la instrucción transmite o bien un informe de evento de respuesta de error de instrucción o bien uno o más informes de evento de datos de archivo. El dispositivo que recibe la instrucción enviará la respuesta de error de instrucción si el archivo no existe en el dispositivo o si los contenidos del archivo están corrompidos. Si no hay archivos a notificar, el dispositivo envía informes de evento de datos de archivo al dispositivo solicitante. En el caso en el que la cantidad de datos de archivo es mayor de la que puede transmitirse con una única APDU (es decir mayor que el tamaño de APDU máxima), el dispositivo enviará informes de eventos sucesivos de tamaño de APDU máximo hasta que los datos de archivo se agoten. El último informe de evento que contiene datos de archivo puede indicarse enviando un informe de evento con una longitud que es menor que el tamaño de APDU máximo o un informe de evento que contiene una entrada de datos de archivo de longitud cero.
Res uesta de error de instrucción de RPC:
Informe de evento de datos de archivo de RPC:
El gestor puede configurarse para ordenar al dispositivo que cancele la transferencia de archivo en cualquier momento enviando una instrucción de cancelar leer archivo al dispositivo. En este evento el dispositivo puede cancelar la transferencia de datos de archivo y enviar una respuesta de cancelación de transferencia de archivo al gestor. Si se producen errores durante la ejecución de esta instrucción, el gestor descartará todos los datos de archivo recibidos (si se hubiera recibido alguno).
Una segunda instrucción de I/O de archivos ilustrativa es la instrucción de escribir datos de archivo. La instrucción de escribir datos de archivo ordena a un dispositivo que se está escribiendo que reciba contenidos de un archivo especificado como uno o más informes de evento de datos de archivo. En una realización ilustrativa, el evento de datos de archivo suministra los contenidos del archivo de forma secuencial. Se aprecia que en otras realizaciones, el evento de datos de archivo también puede suministrar los contenidos del archivo de forma no secuencial. El tamaño de APDU sucesivas de informe de evento de datos de archivo es igual al valor devuelto por la instrucción de RPC_CMD_OPERATIONAL_INFO | RPC_SUBCMD_MAX_APDU_SIZE. Se observa, sin embargo, la última APDU de informe de evento, que puede ser una longitud que es menor que el valor de tamaño de APDU máximo. Lo siguiente proporciona una definición de una instrucción de escribir datos de archivo ilustrativa y una respuesta a la misma: Instrucción/Subinstrucción= 0x8202
Parámetros de entrada:
Nombre de archivo Cadena
Modo de escritura Número (Nuevo o Añadir)
Parámetros de salida:
Código de error Número
Invocación de instrucción de RPC:
Informe de evento de datos de archivo de RPC:
Res uesta de error de instrucción de RPC:
T ras recibir la invocación de instrucción, el dispositivo que se está escribiendo envía un informe de evento de respuesta de error al gestor. Una respuesta de RPC_ERR_APPLICATION_ERROR indica que no es posible la operación de
escribir archivo por una de las siguientes razones: o bien el modo de escritura era "Nuevo" y el archivo ya existía en el dispositivo; o bien el modo de escritura era "Añadir" y el archivo no existe en el dispositivo.
Una respuesta de RPC_ERR_INVALID_PARAMETERS indica que el nombre de archivo no es válido o el modo de escritura no es un valor de enumeración legal. Una respuesta de RPC_ERR_HARDWARE indica que el volumen está lleno.
Una respuesta de error de RPC_ERR_NO_ERRORS desencadena que el gestor envíe uno o más informes de evento de datos de archivo. En el caso en el que la cantidad de datos de archivo es mayor de la que puede transmitirse con una única APDU (es decir mayor que el tamaño de APDU máxima), el gestor enviará informes de eventos sucesivos de tamaño de APDU máximo hasta que los datos de archivo se agoten. El último informe de evento que contiene datos de archivo se indicará enviando un informe de evento con una longitud que es menor que el tamaño de APDU máximo o un informe de evento que contiene una entrada de datos de archivo de longitud cero.
T ras recibir el último informe de evento de datos de archivo, el dispositivo que se está escribiendo verifica la integridad del archivo analizando la firma digital contenida dentro de los datos de archivo. Si la comprobación de integridad de archivo falla, el dispositivo que se está escribiendo envía una respuesta de RPC_ERR_SECURITY_ERROR al gestor.
Si se supera la comprobación de integridad de archivo, el dispositivo que se está escribiendo escribe el archivo a la ubicación especificada por la trayectoria. Si el dispositivo encuentra un error en el proceso de escribir los datos de archivo a la ubicación especificada, el dispositivo envía una respuesta de RPC_e Rr_HARDWARE al gestor. Si el dispositivo escribe satisfactoriamente los datos de archivo a la ubicación especificada, el dispositivo envía una respuesta de RPC_ERR_NO_ERRORS al gestor. Si se producen errores durante la ejecución de esta instrucción, el dispositivo descartará todos los datos de archivo recibidos (si se hubiera recibido alguno).
Como se analizará a continuación, que el dispositivo puede ordenar al gestor que cancele la transferencia de archivo en cualquier momento enviando un informe de evento de cancelar escribir archivo al gestor. En este evento el gestor puede cancelar inmediatamente la transferencia de datos de archivo.
Como se ha mencionado, el conjunto de instrucciones incluye una instrucción de cancelar leer archivo. La instrucción de cancelar leer archivo ordena a un dispositivo que recibe una instrucción de leer archivo que cancele la transferencia de datos de archivo iniciada por la instrucción de leer archivo. La instrucción devuelve un código de error que indica éxito (RPC_ERR_NO_ERRORS) o RPC_ERR_APPLICATION_ERROR en el evento de fallo. Lo siguiente proporciona una definición ilustrativa de la instrucción de leer archivo y una respuesta a la misma:
Instrucción/Subinstrucción= 0x8203
Parámetros de entrada:
Ninguno
Parámetros de salida:
Código de error Número
Invocación de instrucción de RPC:
continuación
Res uesta de instrucción de RPC:
Como se ha mencionado, un dispositivo que recibió la instrucción de escribir archivo puede generar y transmitir un informe de evento de cancelar escribir archivo. El informe de evento de cancelar escribir archivo tiene una estructura similar a una instrucción pero no es necesariamente una instrucción, ya que el informe de evento de cancelar escribir archivo no desencadena una respuesta por el gestor que emitió la instrucción de escribir archivo. En su lugar, el informe de evento de cancelar escribir archivo ordena al gestor que cancele la transferencia de escribir datos de archivo. Se observa que en algunas realizaciones, el dispositivo que emite el informe de evento de cancelar escribir
archivo también puede especificar un valor de código de error para indicar la causa de cancelar escribir archivo, que podría ser RPC_ERR_APPLICATION ERROR o RPC_ERR_hA r DWARE (indicando que el volumen está lleno). Los siguiente define una definición ilustrativa de un informe de evento de cancelar escribir archivo:
Informe de evento de cancelar escribir archivos de RPC:
El conjunto de instrucciones de I/O de archivos incluye adicionalmente una instrucción de borrar archivo. La instrucción de borrar archivo se emite por el gestor y ordena al dispositivo que recibe la instrucción que borre el archivo especificado. En respuesta a la instrucción, el dispositivo devuelve un código de error que indica éxito, por ejemplo RPC_ERR_NO_ERRORS, o uno de los siguientes códigos de error en el evento de fallo: RPC_ERR_INVALID_PARAMETERS si el archivo no existe en el dispositivo; o RPC_ERR_APPLICATION_ERROR si el archivo está protegido por el dispositivo y no puede borrarse. Lo siguiente define una definición ilustrativa de una instrucción de borrar archivo y una respuesta a la misma:
Instrucción/Subinstrucción= 0x8204
Parámetros de entrada:
Nombre de archivo Cadena
Parámetros de salida:
Código de error Número
Invocación de instrucción de RPC:
Res uesta de instrucción de RPC:
El conjunto de instrucciones también puede incluir una instrucción de leer directorio de archivo. La instrucción de leer directorio de archivo ordena al dispositivo que recibe la instrucción que devuelva una lista de archivos/carpetas de cadenas de caracteres, cada una de las cuales especifica una entada de archivo/carpeta en la lista de archivo de la trayectoria especificada. El dispositivo enviará una respuesta de error de instrucción si la trayectoria no existe en el dispositivo, por ejemplo RPC_ERR_INVALID_PARAMETERS, o si los contenidos de la trayectoria están corrompidos, por ejemplo RPC_ERR_APPLICATION. El formato del nombre de trayectoria y las entradas de lista de archivo depende de la implementación de sistema de archivos del dispositivo que recibe la petición. La lista de archivos no incluye los contenidos de cualquier subdirectorio que existe dentro de la carpeta de la trayectoria especificada. Lo siguiente define una definición ilustrativa de una instrucción de leer directorio de archivo y una respuesta a la misma: Instrucción/Subinstrucción= 0x8205 Parámetros de entrada:
Nombre de trayectoria Cadena
Parámetros de salida:
Matriz de lista de archivos [] Cadena
Invocación de instrucción de RPC:
Res uesta de instrucción de RPC:
Se aprecia que las anteriores definiciones de instrucciones, definiciones de respuesta, valores de instrucción e instrucciones son ilustrativas. Otras definiciones y valores se contemplan y están dentro del alcance de esta divulgación.
Haciendo referencia ahora a las Figuras 10A y 10B, se representa un método ilustrativo para realizar comunicación de transferencia. Se aprecia que una o más de las instrucciones descritas anteriormente pueden usarse para efectuar comunicación de transferencia entre un dispositivo informático externo y un dispositivo médico. Se aprecia que comunicaciones entre el dispositivo informático externo 600 y el controlador de diabetes 500 están de acuerdo con la norma IEEE 11073. Adicionalmente, en este ejemplo, el dispositivo informático externo 600 comunica con el controlador de diabetes 500 a través de una trayectoria de comunicación bidireccional por cable, por ejemplo USB, y el dispositivo médico 700 comunica con el controlador de diabetes 500 a través de una trayectoria de comunicación bidireccional inalámbrica, por ejemplo Bluetooth.
Comunicación de transferencia puede iniciarse con una instrucción de habilitar transferencia, como se muestra en la etapa 1010. Como se ha analizado, el dispositivo informático externo 600 transmite una instrucción que tiene un valor de instrucción/subinstrucción, por ejemplo 0x8701, y un identificador de dispositivo. Tras recibir la instrucción, el controlador de diabetes 500 analizará la instrucción de habilitar transferencia y determinará con qué dispositivo médico establecer una trayectoria de comunicación de transferencia e intentará establecer una trayectoria de comunicación de transferencia con el mismo, como se muestra en la etapa 1012. Tras recibir la instrucción de habilitar transferencia, el controlador de diabetes 500 confirmará que se habilita comunicación con el dispositivo médico 700 seleccionado. En algunas realizaciones, esto puede conseguirse enviando una comunicación de prueba o similar al dispositivo médico 700. En otras realizaciones, se envía al dispositivo médico 700 un mensaje que indica que se habilita comunicación de transferencia. En algunas realizaciones, el dispositivo médico 700 confirmará que se establece una trayectoria de comunicación, como se muestra en la etapa 1014. Si el dispositivo no existe o la trayectoria de comunicación no puede establecerse, el controlador de diabetes 500 determina que la trayectoria de comunicación de transferencia no puede establecerse, etapa 1016, y transmite una respuesta de error, por ejemplo, RPC_ERR_APPLICATION_ERROR, al dispositivo informático externo 600. Si se determina que se ha establecido una trayectoria de comunicación de transferencia, etapa 1016, el controlador de diabetes 500 transmite una respuesta que indica que la trayectoria de comunicación de transferencia se ha establecido, etapa 1020, por ejemplo RPC_ERR_NO_ERRORS.
Una vez que se ha establecido una trayectoria de comunicación de transferencia, puede comenzar la comunicación de transferencia, como se muestra en la etapa 1022. El dispositivo informático externo 600 enviará a continuación una instrucción de transferencia al controlador de diabetes. Mientras el presente ejemplo ilustra la trayectoria de comunicación externa transmitiendo instrucciones de transferencia al controlador de diabetes 500, se aprecia que el dispositivo médico 700 puede transmitir mensajes de comunicación de transferencia de manera similar. Se aprecia que las etapas a continuación de la transmisión de una instrucción de transferencia son sustancialmente las mismas que si se envían desde el dispositivo médico 700.
Como se ha analizado anteriormente, una instrucción de transferencia incluye el valor de instrucción/subinstrucción de una instrucción de transferencia, por ejemplo 0x8703, y la carga útil del mensaje de transferencia almacenado en una matriz de datos de carga útil. Por lo tanto, el dispositivo informático externo 600 recuperará los datos a comunicar al dispositivo médico desde una memoria intermedia de transmisión e insertará los datos en la matriz de datos de carga útil. El dispositivo informático externo 600 formateará adicionalmente la instrucción de transferencia según sea necesario, y también puede cifrar la instrucción. Una vez que la instrucción se genera, el dispositivo informático externo 600 empaquetará la instrucción en un primer paquete de datos que tiene una primera estructura de paquete de datos que es adecuado para transmisión en el enlace de comunicación por cable. Como se ha analizado anteriormente, el primer paquete de datos tendrá una estructura que corresponde al protocolo de comunicación del protocolo por cable,
por ejemplo un paquete de USB. Una vez que la instrucción de transferencia se empaqueta y está lista para transmisión, el dispositivo informático externo 600 transmitirá la instrucción de transferencia al controlador de diabetes 500.
El controlador de diabetes 500 recibe el paquete de datos que contiene la instrucción de transferencia. El controlador de diabetes 500 a continuación desempaquetará el primer paquete de datos, etapa 1026, y se asegurará que la instrucción no es una instrucción de deshabilitar transferencia (no mostrado). El controlador de diabetes 500 empaquetará de nuevo la carga útil en un segundo paquete de datos que tiene una segunda estructura de paquete de datos que es adecuada para transmisión en el enlace de comunicación inalámbrico, como se muestra en 1028. Las etapas anteriores pueden conseguirse analizando el primer paquete de datos para determinar los datos de carga útil. Los datos de carga útil estarán en un campo predefinido de acuerdo con el protocolo de comunicación del enlace de comunicación por cable. El controlador de diabetes a continuación generará el segundo paquete de datos de acuerdo con el protocolo de comunicación del enlace de comunicación inalámbrico, por ejemplo Bluetooth. El paquete de datos generado incluirá los datos de carga útil recibidos en el primer paquete de datos.
El controlador de diabetes 500 transmite el segundo paquete de datos al dispositivo médico 1030 a través del enlace de comunicación inalámbrico. Si el dispositivo médico 700 recibe el segundo paquete de datos, el dispositivo médico 700 transmite un acuse de recibo al controlador de diabetes 500, como se muestra en la etapa 1030. El dispositivo médico 700 a continuación ejecuta la instrucción contenida en la carga útil, por ejemplo I/O de archivos.
El controlador de diabetes 500 a continuación determina si la transmisión fue satisfactoria y la carga útil se recibió por el dispositivo médico 700, como se muestra en la etapa 1034. Si la transmisión no fue satisfactoria, el controlador de diabetes 500 transmitirá un código de error de transferencia, por ejemplo RPC_ERR_APPLICATION_ERROR, al dispositivo informático externo 600, como se muestra en 1036. Si, sin embargo, la transmisión fue satisfactoria, el controlador de diabetes generará y transmitirá un código de error que indica una transmisión satisfactoria, por ejemplo RPC_ERR_NO_ERRORS.
El dispositivo informático externo recibe el código de error que indica una transmisión no satisfactoria o satisfactoria, como se muestra en la etapa 1040. Si el código de error indicó una transmisión no satisfactoria o la transmisión fue satisfactoria y hay más cargas útiles para transmitir, el dispositivo informático externo continúa generando instrucciones de transferencia, por ejemplo vuelve a la etapa 1024.
Si el dispositivo informático externo 600 y el dispositivo médico 700 han finalizado de intercambiar datos, a continuación el dispositivo informático externo 600 emitirá y transmitirá una instrucción de deshabilitar transferencia. La instrucción de deshabilitar transferencia incluye un valor de instrucción/subinstrucción, por ejemplo 0x8702. Como se ha analizado anteriormente, el controlador de diabetes 500 comprueba cada paquete para garantizar que el paquete de datos no contiene una instrucción de deshabilitar transferencia. Una vez que se recibe la instrucción de deshabilitar transferencia, etapa 1048, el controlador de diabetes 500 deshabilita la trayectoria de comunicación de transferencia.
El método mostrado anteriormente proporciona un ejemplo de un método que utiliza las instrucciones para comunicaciones de transferencia descritas anteriormente. Adicionalmente, el método anterior puede adicionalmente utilizar instrucciones tales como las instrucciones de I/O de archivos e instrucciones de actualizar firmware para efectuar acciones tales como leer un archivo de un dispositivo médico o actualizar el firmware de un dispositivo médico. Lo anterior no es limitante y otros métodos también pueden utilizar las instrucciones para comunicaciones de transferencia, I/O de archivos y actualizaciones de firmware.
En vista de la anterior divulgación, se ha divulgado un sistema de control de diabetes. El sistema de control de diabetes configurado para permitir comunicación de transferencia. El sistema de control de diabetes incluye un dispositivo de control de diabetes, un dispositivo informático externo que comunica con el dispositivo de control de diabetes a través de un primer enlace de comunicaciones bidireccional. El dispositivo de control de diabetes y el dispositivo informático externo intercambian primeros paquetes de datos de una primera estructura de paquete de datos a través del primer enlace de comunicación bidireccional. El sistema de control de diabetes incluye adicionalmente un primer dispositivo médico que realiza una tarea relacionada con control de diabetes y que comunica con el dispositivo de control de diabetes a través de un segundo enlace de comunicaciones bidireccional; en el que el dispositivo de control de diabetes y el primer dispositivo médico intercambian segundos paquetes de datos de una segunda estructura de paquete de datos a través del segundo enlace de comunicación bidireccional. El dispositivo de control de diabetes incluye un módulo de transferencia que:
v) establece selectivamente una trayectoria de comunicación de transferencia entre el dispositivo informático externo y el primer dispositivo médico,
vi) recibe primeros paquetes de datos de la primera estructura de paquete de datos desde el dispositivo informático externo a través del primer enlace de comunicaciones bidireccional,
vii) convierte los primeros paquetes de datos en segundos paquetes de datos de la segunda estructura de paquete de datos, y
viii) transmite los segundos paquetes de datos al primer dispositivo médico a través del segundo enlace de comunicaciones bidireccional;
El módulo de transferencia usa un conjunto de instrucciones de transferencia para establecer una trayectoria de comunicación de transferencia y habilitar comunicación entre el dispositivo informático externo y el primer dispositivo médico, y en el que el conjunto de instrucciones de transferencia se define de conformidad con un protocolo de comunicación definido de acuerdo con la norma de IEEE 11073-20601.
En un aspecto adicional de la divulgación, el sistema de control de diabetes comprende además un segundo dispositivo médico que realiza una tarea diferente relacionada con control de diabetes y que comunica con el dispositivo de control de diabetes a través de un tercer enlace de comunicaciones bidireccional. El dispositivo de control de diabetes y el segundo dispositivo médico intercambian terceros paquetes de datos de una tercera estructura de paquete de datos a través del tercer enlace de comunicación bidireccional. Además el módulo de transferencia establece selectivamente una segunda trayectoria de comunicación de transferencia entre el dispositivo informático externo y el segundo dispositivo médico.
En un aspecto adicional de la divulgación, el conjunto de instrucciones de transferencia incluye una instrucción de habilitar transferencia para habilitar comunicación de transferencia para uno del primer dispositivo médico y el segundo dispositivo médico, en el que la instrucción incluye un identificador de dispositivo que indica con cuál del primer dispositivo médico y el segundo dispositivo médico para habilitar comunicación de transferencia.
En un aspecto adicional de la divulgación, el módulo de transferencia, en respuesta a la instrucción de habilitar primera trayectoria de comunicación y la segunda trayectoria de comunicación basándose en el identificador de dispositivo en la instrucción de habilitar transferencia.
En un aspecto adicional de la divulgación, el conjunto de instrucciones de transferencia incluye una instrucción de transmitir carga útil de transferencia que ordena al control de diabetes que transmita la primera carga útil de paquete de datos desde el dispositivo informático externo al primer dispositivo médico, en el que la instrucción de transmitir carga útil de transferencia incluye una carga útil del primer paquete de datos.
En un aspecto adicional de la divulgación, el módulo de transferencia, en respuesta a una instrucción de transmitir carga útil de transferencia recibida desde el dispositivo informático externo, genera el segundo paquete de datos insertando la carga útil del primer paquete de datos en el segundo paquete de datos, y transmite el segundo paquete de datos al primer dispositivo médico a través del segundo enlace de comunicación.
En un aspecto adicional de la divulgación, el módulo de transferencia transmite un informe de evento de datos de carga útil al dispositivo informático externo cuando el segundo paquete de datos se transmite satisfactoriamente al primer dispositivo médico y una respuesta de error cuando el segundo paquete de datos no se transmite satisfactoriamente al primer dispositivo médico.
En un aspecto adicional de la divulgación, el primer enlace de comunicación es un enlace de comunicación por cable y el segundo enlace de comunicación es un enlace de comunicación inalámbrico.
En un aspecto adicional de la divulgación, el primer dispositivo médico es uno de una bomba de insulina durable, una bomba de insulina no durable, un monitor de glucosa continuo y un dispositivo móvil.
En un aspecto adicional de la divulgación, el módulo de transferencia se configura adicionalmente para recibir segundos paquetes de datos de la segunda estructura de paquete de datos desde el primer dispositivo médico a través del segundo enlace de comunicaciones bidireccional, convertir los segundos paquetes de datos en primeros paquetes de datos de la primera estructura de paquete de datos, y transmitir los primeros paquetes de datos al dispositivo informático externo a través del primer enlace de comunicaciones bidireccional.
Adicionalmente, se ha descrito un dispositivo de control de diabetes configurado para proporcionar una trayectoria de comunicación de transferencia eficiente entre un primer dispositivo médico y un dispositivo informático externo. El dispositivo de control de diabetes incluye un primer módulo de comunicaciones configurado para establecer un primer enlace de comunicaciones bidireccional con el dispositivo informático externo. El dispositivo de control de diabetes y el dispositivo informático externo intercambian primeros paquetes de datos de una primera estructura de paquete de datos a través del primer enlace de comunicación bidireccional. El dispositivo de control de diabetes incluye adicionalmente un segundo módulo de comunicaciones configurado para establecer un segundo enlace de comunicaciones bidireccional con el primer dispositivo médico. El dispositivo de control de diabetes y el primer dispositivo médico intercambian segundos paquetes de datos de una segunda estructura de paquete de datos a través del segundo enlace de comunicación bidireccional. El dispositivo de control de diabetes comprende además un módulo de transferencia que:
v) establece selectivamente una trayectoria de comunicación de transferencia entre el dispositivo informático externo y el primer dispositivo médico,
vi) recibe primeros paquetes de datos de la primera estructura de paquete de datos desde el dispositivo informático externo a través del primer enlace de comunicaciones bidireccional,
vii) convierte los primeros paquetes de datos en segundos paquetes de datos de la segunda estructura de paquete
de datos, y
viii) transmite los segundos paquetes de datos al primer dispositivo médico a través del segundo enlace de comunicaciones bidireccional;
El módulo de transferencia usa un conjunto de instrucciones de transferencia para establecer una trayectoria de comunicación de transferencia y habilitar comunicación entre el dispositivo informático externo y el primer dispositivo médico, y en el que el conjunto de instrucciones de transferencia se define de conformidad con un protocolo de comunicación definido de acuerdo con la norma de IEEE 11073-20601.
Mientras lo anterior se ha descrito con respecto a sistemas de control de diabetes, se entiende que las instrucciones de comunicación de transferencia pueden usarse en otros sistemas de dispositivos médicos. La norma IEEE 11073 se extiende a otros dispositivos médicos y en vista de lo anterior divulgación, la aplicabilidad de extensión privada del solicitante de la norma IEEE 11073 a otros sistemas de dispositivos médicos debería ser evidente para un experto en la materia.
La siguiente descripción es meramente ilustrativa en naturaleza y de ninguna forma pretende limitar la divulgación, su aplicación o uso. Para propósitos de claridad, los mismos números de referencia se usarán en los dibujos para identificar elementos similares. Como se usa en este documento, la frase al menos uno de A, B y C debería interpretarse que significa una lógica (A o B o C), usando una lógica no exclusiva o. Debería entenderse que etapas dentro de un método pueden ejecutarse en diferente orden sin alterar los principios de la presente divulgación.
Como se usa en este documento, el término módulo puede referirse a, ser parte de, o incluir un circuito integrado de aplicación específica (ASIC); un circuito electrónico; un circuito lógico combinacional; un campo de matriz de puertas programables (FPGA); un procesador (compartido, especializado o grupo) que ejecuta código; otros componentes adecuados que proporcionan la funcionalidad descrita; o una combinación de alguno de los anteriores, tal como en un sistema en chip. El término módulo puede incluir memoria (compartida, especializada o grupo) que almacena código ejecutado por el procesador.
El término código, como se usa anteriormente, puede incluir software, firmware y/o microcódigo, y puede referirse a programas, rutinas, funciones, clases y/u objetos. El término compartido, como se usa anteriormente, significa que parte o todo el código de múltiples módulos puede ejecutarse usando un único procesador (compartido). Además, parte o todo el código de múltiples módulos puede almacenarse mediante una única memoria (compartida). El término grupo, como se usa anteriormente, significa que parte o todo el código de un único módulo puede ejecutarse usando un grupo de procesadores. Además, parte o todo el código de un único módulo puede almacenarse usando a grupo de memorias.
Los aparatos y métodos descritos en este documento pueden implementarse mediante uno o más programas informáticos ejecutados por uno o más procesadores. Los programas informáticos incluyen instrucciones ejecutables por procesador que se almacenan en un medio legible por ordenador tangible no transitorio. Los programas informáticos también pueden incluir datos almacenados. Ejemplos no limitantes del medio legible por ordenador tangible no transitorio son memoria no volátil, almacenamiento magnético y almacenamiento óptico.
ANEXO A
Atributos de obeto numérico de RPC comunes
ANEXO B
Enumeraciones de error de respuesta de instrucción
RPC_ERR_NO_ERRORS 0x0000 RPC_ERR_CMD_CANCELLED 0x0001 RPC_ERR_BLOCK_LENGTH 0x0002
RPC ERR INVALID PARAMETERS 0x0003
O bien el número de parámetros o bien el contenido no es válido.
RPC_ERR_INVALID_DATA ::= 0x0004 RPC_ERR_UNRECOGNIZED_CMD ::= 0x0005
RPC ERR UNRECOGNIZED FEATURE :: = 0x0006
Este error es aplicable si se reconoce la instrucción, pero no el parámetro.
RPC_ERR_ABORTED_CMD ::= 0x0007
RPC ERR HARDWARE ::= 0x0008
Gestor debe invocar la instrucción de leer y borrar estado para recuperar información de error extendida.
RPC_ERR_APPLICATION ::= 0x0009
Gestor debe invocar la instrucción de leer y borrar estado para recuperar información de error extendida.
RPC_ERR_SECURITY_ERROR ::= 0x000A
Este error indica que un gestor emitió una instrucción que no existe para la función autorizada en la actualidad, o que la comprobación de firma digital de un archivo falla.
Claims (7)
1. Un sistema de control de diabetes configurado para permitir comunicación de transferencia que comprende:
- un dispositivo de control de diabetes (104, 500);
- un dispositivo informático externo (600) que comunica con el dispositivo de control de diabetes (104, 500) a través de un primer enlace de comunicaciones bidireccional, en el que el dispositivo de control de diabetes (104, 500) y el dispositivo informático externo (600) intercambian primeros paquetes de datos de una primera estructura de paquete de datos a través del primer enlace de comunicación bidireccional;
- un primer dispositivo médico (700) que realiza una tarea relacionada con control de diabetes y que comunica con el dispositivo de control de diabetes (104, 500) a través de un segundo enlace de comunicaciones bidireccional; en el que el dispositivo de control de diabetes (104, 500) y el primer dispositivo médico (700) intercambian segundos paquetes de datos de una segunda estructura de paquete de datos a través del segundo enlace de comunicación bidireccional;
el dispositivo de control de diabetes (104, 500) que incluye un módulo de transferencia (512) que:
- establece una trayectoria de comunicación de transferencia entre el dispositivo informático externo (600) y el primer dispositivo médico (700),
- recibe primeros paquetes de datos de la primera estructura de paquete de datos desde el dispositivo informático externo (600) a través del primer enlace de comunicaciones bidireccional,
- convierte los primeros paquetes de datos en segundos paquetes de datos de la segunda estructura de paquete de datos, y
- transmite los segundos paquetes de datos al primer dispositivo médico (700) a través del segundo enlace de comunicaciones bidireccional;
en el que el módulo de transferencia (512) usa un conjunto de instrucciones de transferencia para establecer una trayectoria de comunicación de transferencia y habilitar comunicación entre el dispositivo informático externo (600) y el primer dispositivo médico (700),
caracterizado por que
- el conjunto de instrucciones de transferencia se define como una extensión privada de la norma de IEEE 11073 20601,
- el conjunto de instrucciones de transferencia incluye una instrucción de transmitir carga útil de transferencia recibida desde el dispositivo informático externo (600), en el que la instrucción de transmitir carga útil de transferencia
- ordena al dispositivo de control de diabetes (104, 500) que transmita una carga útil del primer paquete de datos desde el dispositivo informático externo (600) al primer dispositivo médico (700), y
- incluye la carga útil del primer paquete de datos, y
- el módulo de transferencia (512), en respuesta a la instrucción de transmitir carga útil de transferencia, genera el segundo paquete de datos insertando la carga útil del primer paquete de datos en el segundo paquete de datos, y transmite el segundo paquete de datos al primer dispositivo médico (700) a través del segundo enlace de comunicación.
2. El sistema de control de diabetes de la reivindicación 1 comprendiendo además un segundo dispositivo médico que realiza una tarea diferente relacionada con control de diabetes y que comunica con el dispositivo de control de diabetes (104, 500) a través de un tercer enlace de comunicaciones bidireccional, en el que el dispositivo de control de diabetes (104, 500) y el segundo dispositivo médico intercambian terceros paquetes de datos de una tercera estructura de paquete de datos a través del tercer enlace de comunicación bidireccional, en el que el módulo de transferencia (512) establece selectivamente una segunda trayectoria de comunicación de transferencia entre el dispositivo informático externo (600) y el segundo dispositivo médico.
3. El sistema de control de diabetes de la reivindicación 2 en el que el conjunto de instrucciones de transferencia incluye una instrucción de habilitar transferencia para habilitar comunicación de transferencia para uno del primer dispositivo médico (700) y el segundo dispositivo médico, en el que la instrucción incluye un identificador de dispositivo que indica con cuál del primer dispositivo médico (700) y el segundo dispositivo médico habilitar comunicación de transferencia.
4. El sistema de control de diabetes de la reivindicación 3 en el que el módulo de transferencia (512), en respuesta a la instrucción de habilitar transferencia recibida desde el dispositivo informático externo (600), establece únicamente una de la primera trayectoria de comunicación y la segunda trayectoria de comunicación basándose en el identificador de dispositivo en la instrucción de habilitar transferencia.
5. El sistema de control de diabetes de al menos una de las reivindicaciones anteriores en el que el módulo de transferencia (512) transmite un informe de evento de datos de carga útil al dispositivo informático externo (600) cuando el segundo paquete de datos se transmite satisfactoriamente al primer dispositivo médico (700) y una
respuesta de error cuando el segundo paquete de datos no se transmite satisfactoriamente al primer dispositivo médico (700).
6. El sistema de control de diabetes de al menos una de las reivindicaciones anteriores en el que el primer dispositivo médico (700) es uno de una bomba de insulina durable, una bomba de insulina no durable, un monitor de glucosa continuo y un dispositivo móvil.
7. El sistema de control de diabetes de al menos una de las reivindicaciones anteriores en el que el módulo de transferencia (512) se configura adicionalmente para recibir segundos paquetes de datos de la segunda estructura de paquete de datos desde el primer dispositivo médico (700) a través del segundo enlace de comunicaciones bidireccional, convertir los segundos paquetes de datos en primeros paquetes de datos de la primera estructura de paquete de datos, y transmitir los primeros paquetes de datos al dispositivo informático externo (600) a través del primer enlace de comunicaciones bidireccional.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US12/976,313 US8672874B2 (en) | 2010-12-22 | 2010-12-22 | Communication protocol that supports pass-thru communication |
| PCT/EP2011/006485 WO2012084235A1 (en) | 2010-12-22 | 2011-12-21 | Communication protocol that supports pass-thru communication |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2741173T3 true ES2741173T3 (es) | 2020-02-10 |
Family
ID=45445980
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES11804960T Active ES2741173T3 (es) | 2010-12-22 | 2011-12-21 | Protocolo de comunicación que soporta comunicación de transferencia |
Country Status (5)
| Country | Link |
|---|---|
| US (2) | US8672874B2 (es) |
| EP (1) | EP2656254B1 (es) |
| DK (1) | DK2656254T3 (es) |
| ES (1) | ES2741173T3 (es) |
| WO (1) | WO2012084235A1 (es) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20210187195A1 (en) * | 2017-10-12 | 2021-06-24 | Microtech Medical (Hangzhou) Co.,Ltd. | Cloud big data-based system and method for insulin pump individualized configuration optimization |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9238100B2 (en) | 2012-06-07 | 2016-01-19 | Tandem Diabetes Care, Inc. | Device and method for training users of ambulatory medical devices |
| US9253247B2 (en) * | 2012-11-21 | 2016-02-02 | Signove Tecnologia S/A | Transcoding of communication with personal health devices |
| US9242043B2 (en) * | 2013-03-15 | 2016-01-26 | Tandem Diabetes Care, Inc. | Field update of an ambulatory infusion pump system |
| US9152689B2 (en) * | 2013-06-25 | 2015-10-06 | International Business Machines Corporation | Managing passthru connections on an operator graph |
| ES2903156T3 (es) * | 2015-10-16 | 2022-03-31 | Hoffmann La Roche | Un procedimiento para hacer funcionar un sistema y un sistema |
| US10541987B2 (en) | 2016-02-26 | 2020-01-21 | Tandem Diabetes Care, Inc. | Web browser-based device communication workflow |
| USD853583S1 (en) | 2017-03-29 | 2019-07-09 | Becton, Dickinson And Company | Hand-held device housing |
| US20210334380A1 (en) * | 2020-04-24 | 2021-10-28 | Vmware, Inc. | Trusted firmware verification |
| WO2022072973A1 (en) | 2020-09-30 | 2022-04-07 | Boston Scientific Neuromodulation Corporation | Pairing of external communication devices with an implantable medical device via a patient remote controller |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7647237B2 (en) | 1998-04-29 | 2010-01-12 | Minimed, Inc. | Communication station and software for interfacing with an infusion pump, analyte monitor, analyte meter, or the like |
| US6175752B1 (en) | 1998-04-30 | 2001-01-16 | Therasense, Inc. | Analyte monitoring device and methods of use |
| CA2345043C (en) | 1998-10-08 | 2009-08-11 | Minimed, Inc. | Telemetered characteristic monitor system |
| US6424847B1 (en) | 1999-02-25 | 2002-07-23 | Medtronic Minimed, Inc. | Glucose monitor calibration methods |
| US6895263B2 (en) | 2000-02-23 | 2005-05-17 | Medtronic Minimed, Inc. | Real time self-adjusting calibration algorithm |
| US6816744B2 (en) | 2001-05-29 | 2004-11-09 | Reproductive Health Technologies, Inc. | Device and system for remote for in-clinic trans-abdominal/vaginal/cervical acquisition, and detection, analysis, and communication of maternal uterine and maternal and fetal cardiac and fetal brain activity from electrical signals |
| US6490470B1 (en) | 2001-06-19 | 2002-12-03 | Optosonics, Inc. | Thermoacoustic tissue scanner |
| US20040068230A1 (en) | 2002-07-24 | 2004-04-08 | Medtronic Minimed, Inc. | System for providing blood glucose measurements to an infusion device |
| US6931327B2 (en) | 2003-08-01 | 2005-08-16 | Dexcom, Inc. | System and methods for processing analyte sensor data |
| EP1758039A1 (de) | 2005-08-27 | 2007-02-28 | Roche Diagnostics GmbH | Kommunikations-Adapter für ambulante medizinische oder therapeutische Geräte |
| US7630748B2 (en) | 2006-10-25 | 2009-12-08 | Abbott Diabetes Care Inc. | Method and system for providing analyte monitoring |
| US8073008B2 (en) * | 2006-04-28 | 2011-12-06 | Medtronic Minimed, Inc. | Subnetwork synchronization and variable transmit synchronization techniques for a wireless medical device network |
| US20070255125A1 (en) | 2006-04-28 | 2007-11-01 | Moberg Sheldon B | Monitor devices for networked fluid infusion systems |
| US8126728B2 (en) | 2006-10-24 | 2012-02-28 | Medapps, Inc. | Systems and methods for processing and transmittal of medical data through an intermediary device |
| EP2001188A1 (en) | 2007-06-08 | 2008-12-10 | F.Hoffmann-La Roche Ag | Method for authenticating a medical device and a remote device |
| US8449523B2 (en) | 2007-06-15 | 2013-05-28 | Animas Corporation | Method of operating a medical device and at least a remote controller for such medical device |
| US8444595B2 (en) | 2007-06-15 | 2013-05-21 | Animas Corporation | Methods to pair a medical device and at least a remote controller for such medical device |
| US8932250B2 (en) | 2007-06-15 | 2015-01-13 | Animas Corporation | Systems and methods to pair a medical device and a remote controller for such medical device |
| CA2930689C (en) | 2008-04-01 | 2020-04-14 | Deka Products Limited Partnership | Methods and systems for controlling an infusion pump |
| US7826382B2 (en) | 2008-05-30 | 2010-11-02 | Abbott Diabetes Care Inc. | Close proximity communication device and methods |
| KR101274111B1 (ko) * | 2008-12-22 | 2013-06-13 | 한국전자통신연구원 | 유니버셜 헬스 플랫폼을 이용한 헬스케어 시스템 및 방법 |
| EP2434944B1 (en) | 2009-05-29 | 2014-12-03 | Abbott Diabetes Care, Inc. | Glucose monitoring system with wireless communications |
| US8861731B2 (en) | 2010-10-15 | 2014-10-14 | Roche Diagnostics Operations, Inc. | Efficient procedure for pairing medical devices for wireless communication with limited user interaction |
-
2010
- 2010-12-22 US US12/976,313 patent/US8672874B2/en active Active
-
2011
- 2011-12-21 EP EP11804960.0A patent/EP2656254B1/en active Active
- 2011-12-21 ES ES11804960T patent/ES2741173T3/es active Active
- 2011-12-21 WO PCT/EP2011/006485 patent/WO2012084235A1/en active Application Filing
- 2011-12-21 DK DK11804960.0T patent/DK2656254T3/da active
-
2014
- 2014-01-09 US US14/151,162 patent/US9056169B2/en active Active
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20210187195A1 (en) * | 2017-10-12 | 2021-06-24 | Microtech Medical (Hangzhou) Co.,Ltd. | Cloud big data-based system and method for insulin pump individualized configuration optimization |
| US11786656B2 (en) * | 2017-10-12 | 2023-10-17 | Microtech Medical (Hangzhou) Co., Ltd. | Cloud big data-based system and method for insulin pump individualized configuration optimization |
Also Published As
| Publication number | Publication date |
|---|---|
| US8672874B2 (en) | 2014-03-18 |
| US20120165728A1 (en) | 2012-06-28 |
| DK2656254T3 (da) | 2019-08-19 |
| US9056169B2 (en) | 2015-06-16 |
| EP2656254A1 (en) | 2013-10-30 |
| EP2656254B1 (en) | 2019-05-29 |
| WO2012084235A1 (en) | 2012-06-28 |
| US20140128804A1 (en) | 2014-05-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2741173T3 (es) | Protocolo de comunicación que soporta comunicación de transferencia | |
| EP2016746B1 (en) | Router device and data communication techniques for networked fluid infusion systems | |
| US9760363B2 (en) | Systems for remote provisioning of electronic devices | |
| US9696980B2 (en) | Method for remote provisioning of electronic devices by overlaying an initial application image with a retrieved application image | |
| ES2701234T3 (es) | Aparato de tratamiento con activación de herramienta médica | |
| US8954719B2 (en) | Method for remote provisioning of electronic devices by overlaying an initial image with an updated image | |
| EP2628104B1 (en) | Use of a handheld medical device as a communications mediator between a personal computer-based configurator and another networked medical device | |
| US8861731B2 (en) | Efficient procedure for pairing medical devices for wireless communication with limited user interaction | |
| US20120165614A1 (en) | Communication protocol for medical devices that supports enhanced security | |
| US20120093315A1 (en) | Diabetes care kit that is preconfigured to establish a secure bidirectional communication link between a blood glucose meter and insulin pump | |
| US20110178462A1 (en) | Remote monitoring for networked fluid infusion systems | |
| ES2710286T3 (es) | Sistema para etiquetar metadatos para un sistema de dispositivos de gestión de diabetes | |
| WO2012048832A1 (en) | Medical devices that support enhanced system extensibility for diabetes care | |
| EP2628107A1 (en) | Communication protocol that supports structured collection procedures used in diabetes care | |
| US8383056B2 (en) | Blood glucose test instrument kit having modular component parts |