ES3013658T3 - Data set distribution during medical device operation - Google Patents

Data set distribution during medical device operation Download PDF

Info

Publication number
ES3013658T3
ES3013658T3 ES16002492T ES16002492T ES3013658T3 ES 3013658 T3 ES3013658 T3 ES 3013658T3 ES 16002492 T ES16002492 T ES 16002492T ES 16002492 T ES16002492 T ES 16002492T ES 3013658 T3 ES3013658 T3 ES 3013658T3
Authority
ES
Spain
Prior art keywords
data set
medical device
unique identifier
target data
downloaded
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES16002492T
Other languages
English (en)
Inventor
Witold Moskal
Maciej Wroblewski
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fenwal Inc
Original Assignee
Fenwal Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fenwal Inc filed Critical Fenwal Inc
Application granted granted Critical
Publication of ES3013658T3 publication Critical patent/ES3013658T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
    • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
    • A61M5/142—Pressure infusion, e.g. using pumps
    • 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
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G16H20/17—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered via infusion or injection
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00—ICT specially adapted for the handling or processing of medical references
    • G16H70/40—ICT specially adapted for the handling or processing of medical references relating to drugs, e.g. their side effects or intended usage
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00—ICT specially adapted for the handling or processing of medical references
    • G16H70/60—ICT specially adapted for the handling or processing of medical references relating to pathologies
    • 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
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/35—Communication
    • A61M2205/3576—Communication with non implanted data transmission devices, e.g. using external transmitter or receiver
    • A61M2205/3584—Communication with non implanted data transmission devices, e.g. using external transmitter or receiver using modem, internet or Bluetooth®
    • 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
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/50—General characteristics of the apparatus with microprocessors or computers
    • A61M2205/502—User interfaces, e.g. screens or keyboards
    • 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
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/60—General characteristics of the apparatus with identification means

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Medical Informatics (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Chemical & Material Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Medicinal Chemistry (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Vascular Medicine (AREA)
  • Anesthesiology (AREA)
  • Biomedical Technology (AREA)
  • Hematology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Animal Behavior & Ethology (AREA)
  • Veterinary Medicine (AREA)
  • Toxicology (AREA)
  • Pharmacology & Pharmacy (AREA)
  • Infusion, Injection, And Reservoir Apparatuses (AREA)

Abstract

Algunos ejemplos proporcionan sistemas, métodos y aparatos para la gestión de dispositivos médicos. Un método de ejemplo incluye comparar la primera identificación de un primer conjunto de datos con la segunda identificación de un segundo conjunto de datos en un dispositivo médico. Este método incluye, cuando la primera identificación no coincide con la segunda, la descarga del segundo conjunto de datos al dispositivo médico. Este método incluye determinar el estado operativo del dispositivo médico. Este método incluye, cuando el estado operativo indica que el dispositivo médico está inactivo, la activación del segundo conjunto de datos en lugar del primero. Este método incluye facilitar el funcionamiento del dispositivo médico según el segundo conjunto de datos. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Distribución de un conjunto de datos durante la operación de un dispositivo sanitario
CAMPO
La presente divulgación se refiere generalmente a dispositivos sanitarios. Más específicamente, la presente divulgación se refiere a métodos, sistemas y aparatos para facilitar la distribución de un conjunto de datos para dispositivos sanitarios.
ANTECEDENTES
Cada vez es más frecuente encontrar dispositivos sanitarios electrónicos o que incluyen un componente electrónico o de software. Los dispositivos electrónicos, las instalaciones distribuidas y los pacientes dispersos dificultan la formación, el tratamiento y la resolución de problemas. Además, a menudo es difícil educar al público, y los pacientes pueden no buscar el tratamiento que deberían debido a la falta de información y acceso. Los técnicos y administradores también pueden introducir ineficacias en su manejo y gestión de los dispositivos sanitarios debido a la falta de información y acceso. Adicionalmente, el acceso y/o la interrupción no autorizados tienen el potencial de introducir errores perjudiciales, así como ineficacias en el tratamiento del paciente.
El documento WO 2013/059615 A1, que representa la técnica anterior más próxima, divulga un método para actualizar dispositivos sanitarios remotos. No obstante, el proceso de actualización del presente documento no garantiza que la versión instalada de las actualizaciones sea la última disponible.
BREVE DESCRIPCIÓN DE DIVERSAS VISTAS DE LOS DIBUJOS
La FIG. 1 ilustra un sistema de gestión de dispositivo sanitario de ejemplo.
La FIG. 2 ilustra un flujo de proceso de distribución de conjunto de datos de ejemplo entre una pluralidad de dispositivos sanitarios.
La FIG. 3 ilustra un diagrama de flujo de datos de ejemplo para la distribución de un conjunto de datos durante la infusión mediante una bomba de infusión de ejemplo.
Las FIGS. 4A-4I representan interfaces de usuario de ejemplo para la creación de reglas de distribución. Las FIGS. 5A-5C representan interfaces de ejemplo de un dispositivo sanitario durante la operación del dispositivo sanitario y la activación del conjunto de datos.
La FIG. 6 representa una interfaz de ejemplo que muestra una pluralidad de dispositivos sanitarios y la información asociada.
La FIG. 7 es un diagrama de bloques de un sistema de monitorización y control de dispositivos sanitarios de ejemplo.
La FIG. 8 es un diagrama de bloques de un sistema procesador de ejemplo que puede usarse para bombear, implementar, controlar y/o accionar los sistemas y métodos aquí descritos.
El sumario anterior, así como la siguiente descripción detallada de determinadas realizaciones de la presente invención, se entenderán mejor al leerse junto con los dibujos adjuntos. Con el fin de ilustrar la invención, en los dibujos se muestran determinadas realizaciones. Debe entenderse, sin embargo, que la presente invención no se limita a las disposiciones e instrumental mostrados en los dibujos adjuntos.
DESCRIPCIÓN DE DETERMINADOS EJEMPLOS
Determinados ejemplos se muestran en las figuras anteriores y se describen con detalle a continuación. Al describir estos ejemplos, se utilizan números de referencia similares o idénticos para identificar elementos similares o iguales. Las figuras no son necesariamente a escala y determinadas características y determinadas vistas de las figuras pueden mostrarse exageradas en escala o en esquema para mayor claridad y/o concisión. Adicionalmente, a lo largo de esta memoria descriptiva se han descrito varios ejemplos. Cualquier característica de cualquier ejemplo puede incluirse, sustituirse o combinarse con otras características de otros ejemplos.
Aunque a continuación se divulgan métodos, aparatos, sistemas y artículos de fabricación de ejemplo, incluyendo, entre otros componentes, firmware y/o software ejecutado en hardware, cabe señalar que tales métodos, aparatos, sistemas y artículos de fabricación son meramente ilustrativos y no deben considerarse limitativos. Por ejemplo, se contempla que cualquiera o todos estos componentes de firmware, hardware y/o software podrían estar incorporados exclusivamente en hardware, exclusivamente en software, exclusivamente en firmware, o en cualquier combinación de hardware, software y/o firmware. Por consiguiente, mientras que a continuación se describen métodos, aparatos, sistemas y/o artículos de fabricación de ejemplo, los ejemplos proporcionados no son la única forma o formas de aplicar tales métodos, aparatos, sistemas y/o artículos de fabricación.
Al introducir elementos de diversas realizaciones de la presente divulgación, los artículos "un", "una", "el", "la", "dicho" y "dicha" pretenden significar que hay uno o más de los elementos. Los términos "que comprende", "que incluye", y "que tiene" pretenden ser inclusivas y significan que puede haber elementos adicionales más allá de los elementos enumerados.
Cuando cualquiera de las reivindicaciones anexas se lee para cubrir una implementación puramente de software y/o firmware, al menos uno de los elementos se define expresamente para incluir un medio tangible como una memoria, un disco de vídeo digital (DVD), un disco compacto (CD), BLU-RAY™, etc. que almacene el software y/o firmware.
Algunos ejemplos facilitan la gestión de dispositivos sanitarios, incluidos los dispositivos de extracción de sangre o aféresis, bombas de infusión, bombas de administración de fármacos y/u otros dispositivos sanitarios. Por ejemplo, una bomba de infusión infunde fluidos, medicamentos o nutrientes a un paciente. Una bomba de infusión puede usarse por vía intravenosa, subcutánea, arterial y/o epidural, por ejemplo. Por ejemplo, una bomba de infusión puede administrar inyecciones a distintas frecuencias (p. ej., inyecciones demasiado pequeñas para un sistema de infusión intravenosa [i.v.] [p. ej., 0,1 ml por hora], inyecciones por minuto, inyecciones con bolos repetidos, inyecciones controladas por el paciente hasta un número máximo por hora, o inyecciones de fluidos cuyos volúmenes varían según la hora del día, etc.).
En ciertos ejemplos, un técnico (p. ej., un auxiliar, un personal de enfermería, etc.) proporciona información sobre el tipo de infusión, el modo y/u otros parámetros del dispositivo. Por ejemplo, la infusión continua proporciona pequeños pulsos de infusión (p. ej., entre 500 nanolitros y 10 mililitros), con una frecuencia de pulso basada en una velocidad de infusión programada. La infusión intermitente alterna entre una velocidad de infusión alta y una velocidad de infusión baja con un tiempo programable para mantener un catéter abierto, por ejemplo. La infusión controlada por el paciente proporciona una infusión a demanda con un límite máximo preprogramado para evitar la intoxicación del paciente. La velocidad de infusión se controla mediante una almohadilla de presión o un botón que puede activar el paciente, por ejemplo. Las bombas de infusión pueden incluir bombas de gran volumen (p. ej., para administrar soluciones nutritivas para alimentar a un paciente), bombas de pequeño volumen (p. ej., para administrar medicamentos), etc.
En ciertos ejemplos, un técnico o administrador puede configurar un dispositivo sanitario, tal como una bomba de infusión, un dispositivo de aféresis, etc., y/o establecer uno o más parámetros para la interacción entre el dispositivo y un controlador de dominio y/o un sistema de gestión de datos de proveedor. Ciertos ejemplos proporcionan flexibilidad para facilitar al técnico y/o administrador (p. ej., un usuario) la operación y la configuración de un dispositivo sanitario manteniendo la fiabilidad y la seguridad del dispositivo mediante nuevos protocolos y sistemas de autorización.
Ciertos ejemplos facilitan la distribución de un conjunto de datos a un dispositivo sanitario, tal como una bomba de infusión, un dispositivo de aféresis, etc., mientras el dispositivo sanitario está en funcionamiento (p. ej., durante la infusión de un paciente a través de la bomba de infusión, etc.). Ciertos ejemplos determinan y/o actualizan una regla de distribución de un conjunto de datos asociada a un sistema de gestión de datos de un dispositivo sanitario (tal como el sistema de gestión de datos Fenwal DXT™, fabricado por Fenwal™, una empresa de Fresenius Kabi). Si se crea una regla de distribución de un conjunto de datos, a continuación, un conjunto de datos nuevo o actualizado (p. ej., una farmacoteca nueva o actualizada) puede distribuirse a uno o más dispositivos sanitarios, incluso si uno o más de los dispositivos sanitarios objetivo están en funcionamiento en ese momento (p. ej., si las bombas están infundiendo fármaco a un paciente). Por tanto, la distribución del conjunto de datos no afecta a la actividad de la bomba.
Por tanto, un sistema de gestión de datos puede interactuar con dispositivos sanitarios (p. ej., Fenwal Amicus™, Alyx™, sistemas de aféresis Autopheresis-C™ y Aurora™, otros dispositivos de aféresis, bomba Fresenius Kabi Agilia®, bomba Optima™, bomba Pilot™, otras bombas de administración de fármacos, etc.) para lograr una configuración y un funcionamiento flexibles y remotos, al tiempo que contribuye a garantizar la seguridad de los datos y la configuración, por ejemplo. La distribución del conjunto de datos no requiere que el dispositivo sanitario (p. ej., la bomba de infusión, el dispositivo de aféresis, etc.) se detenga a mitad de la operación (p. ej., que detenga la infusión, que detenga la extracción de sangre, etc.). La operación del dispositivo sanitario y la distribución del conjunto de datos pueden realizarse simultáneamente.
En ciertos ejemplos, un conjunto de datos define una farmacoteca y/o un conjunto de instrucciones para un dispositivo sanitario, como una bomba de infusión o un dispositivo de aféresis "inteligente", etc. Por ejemplo, las bombas de infusión "inteligentes" utilizan una farmacoteca u otro software de reducción de errores cercanos para realizar funciones que ayudan a los profesionales sanitarios a programar y calcular las dosis de fármacos y las velocidades de administración. La farmacoteca es una base de datos o un conjunto de datos que almacena información sobre la dosificación de fármacos, incluyendo los límites de dosificación, la concentración, los parámetros de infusión y las advertencias específicas de los medicamentos, por ejemplo. Las instrucciones de la farmacoteca pueden ayudar a reducir o prevenir los errores de medicación y los daños asociados a los pacientes, por ejemplo.
En algunos ejemplos, las farmacotecas permiten a los médicos seleccionar medicamentos y fluidos de listas precargadas, que pueden adaptarse a un centro sanitario, un área de atención al paciente, etc. Por ejemplo, un perfil de farmacoteca utilizado en una unidad de cuidados intensivos (UCI) puede incluir medicamentos vasoactivos, pero una farmacoteca para una unidad quirúrgica puede no incluir tales medicamentos. Algunos centros integran también los dispositivos de infusión inteligentes con historiales médicos electrónicos, sistemas informatizados de entrada de pedidos y/o sistemas de escaneado de códigos de barras de medicamentos. La integración de estos sistemas con bombas inteligentes proporciona controles de seguridad adicionales que pueden hacer más segura la administración de medicamentos. Los centros sanitarios pueden optar por aplicar limitaciones, comúnmente denominados límites absolutos y relativos (también denominados límites de dosificación), sobre medicamentos preseleccionados a través de la farmacoteca. Los límites fijan los límites inferior y superior de la dosis, la velocidad de infusión, etc., definidos por el hospital, el sistema sanitario, la clínica, etc. Los límites de dosis y/o velocidad de infusión pueden utilizarse para ayudar al técnico, al médico, etc., a tomar decisiones. Si un médico programa una bomba inteligente fuera de los parámetros predeterminados de dosis o velocidad para un fármaco con límites absolutos, la bomba genera una alerta y no permite al médico continuar con la selección. Normalmente se establecen límites absolutos para los medicamentos de alto riesgo, como la heparina. Con límites relativos, el médico y/u otro usuario autorizado puede anular la alerta y proceder con la infusión, por ejemplo. Las bombas de infusión y/u otros dispositivos pueden generar informes de uso sobre cómo se han utilizado las bombas, qué fármacos se han administrado (p. ej., el tipo, la frecuencia, la dosis, la cantidad total, etc.), las anulaciones de dosis, etc.
La distribución de un conjunto de datos a los dispositivos sanitarios puede realizarse directamente en el dispositivo y/o a distancia a través de una red (p. ej., de un sistema de gestión de datos a varios dispositivos sanitarios, etc.). Sin embargo, la distribución por red inalámbrica de información de conjuntos de datos nuevos a múltiples dispositivos sanitarios ha sido un tema de preocupación para los administradores. Tradicionalmente, la distribución del conjunto de datos de la farmacoteca es un proceso largo que requiere que los dispositivos estén encendidos, inactivos y conectados a una red para recibir una actualización del conjunto de datos. Como resultado, distribuir un conjunto de datos nuevo de manera inalámbrica podía llevar antes varios días. Tal retraso puede causar problemas en la operación del dispositivo sanitario, el tratamiento del paciente, etc.
En ciertos ejemplos, un conjunto de datos objetivo se define para incluir un identificador único asociado a una regla del conjunto de datos programada para la entrega de archivos del conjunto de datos apropiados a la(s) bomba(s) seleccionada(s) durante la distribución del conjunto de datos. Un conjunto de datos descargado se define como un identificador único asociado al archivo del conjunto de datos descargado de un sistema de gestión de datos, pero no programado en la bomba, por ejemplo. Un conjunto de datos programado se define como un identificador único asociado al archivo del conjunto de datos que se está programando actualmente, pero que no está en uso (p. ej., activo) por la bomba, por ejemplo. Un conjunto de datos activo se define como un identificador único asociado con el archivo del conjunto de datos que se está configurando y utilizando actualmente por la bomba, por ejemplo.
En ciertos ejemplos, como el sistema de gestión de dispositivos sanitarios 100 de ejemplo de la FIG. 1, un sistema de gestión de datos 110 recupera y/o genera instrucciones de una colección de datos 120 para formar un conjunto de datos 125. El sistema de gestión de datos 110 comienza a distribuir el conjunto de datos 125 a uno o más dispositivos sanitarios objetivo 130, 135 (es decir, bomba(s), dispositivo(s) de aféresis, etc.) de acuerdo con una regla de distribución determinada. La distribución del conjunto de datos se produce cuando un dispositivo sanitario objetivo 130, 135 detecta que el conjunto de datos objetivo 125 es diferente de su conjunto de datos actual. El dispositivo sanitario 130, 135 se puede utilizar mientras el conjunto de datos nuevo 125 se distribuye desde el sistema de gestión de datos 110 al dispositivo sanitario 130, 135.
La FIG. 2 ilustra un flujo de proceso de distribución de conjunto de datos 200 de ejemplo entre una pluralidad de dispositivos sanitarios. En el bloque 202, el sistema de gestión de datos 110 mantiene un conjunto de datos actual para su distribución a un dispositivo sanitario 130. El dispositivo sanitario 130 puede estar operando en ese momento (p. ej., la(s) bomba(s) puede(n) estar infundiendo, el (los) dispositivo(s) de aféresis puede(n) estar recogiendo producto sanguíneo, etc.).
En el bloque 204, se distribuye un conjunto de datos nuevo al dispositivo sanitario 130. Por ejemplo, el dispositivo sanitario 130 comprueba periódicamente si existe una versión más reciente de su conjunto de datos. Si se encuentra, el dispositivo sanitario 130 descarga y/o recibe de otro modo el conjunto de datos más reciente y verifica el conjunto de datos descargado. El dispositivo 130 almacena el conjunto de datos descargado en un almacenamiento no volátil, por ejemplo. En ciertos ejemplos, una interfaz de usuario del dispositivo sanitario 130 muestra una notificación (p. ej., un icono, etc.) de que el conjunto de datos nuevo está disponible para su programación (p. ej., después de que la bomba haya terminado la infusión en curso, etc.). En ciertos ejemplos, el dispositivo sanitario 130 puede usarse mientras se programa el conjunto de datos nuevo.
En el bloque 206, un usuario apaga el dispositivo sanitario 130 (p. ej., un personal de enfermería apaga la bomba). En el bloque 208, el dispositivo sanitario 130 notifica al sistema de gestión de datos 110 su estado de actualización del conjunto de datos, y se desconecta del sistema de gestión de datos 110 (p. ej., del que ha estado recibiendo la actualización del conjunto de datos). En algunos ejemplos, el dispositivo sanitario se apaga y se vuelve a encender para activar el conjunto de datos recién descargado. En otros ejemplos, el conjunto de datos descargado se activa al finalizar un funcionamiento en curso del dispositivo sanitario 130 (p. ej., una infusión o una recogida actual, etc., en curso en el momento de la descarga y/o instalación del conjunto de datos, etc.).
En el bloque 210, el sistema de gestión de datos 110 almacena el estado de actualización recibido del dispositivo sanitario 130. Se genera información de registro tal como la marca de fecha y hora de la transacción, el tiempo de funcionamiento, el éxito, el fracaso, los errores, etc., y se genera un informe de distribución. El informe de distribución se envía a un usuario, tal como un farmacéutico, etc.
Más específicamente, La FIG. 3 ilustra un diagrama de flujo de datos de ejemplo para la distribución 300 de un conjunto de datos durante la infusión mediante una bomba de infusión de ejemplo. En el bloque 302, se inicia la distribución de un conjunto de datos. Por ejemplo, un farmacéutico puede iniciar la distribución de un conjunto de datos 303 para un dispositivo sanitario, tal como una bomba de infusión, un dispositivo de aféresis, etc., a través del sistema de gestión de datos 110 (p. ej., Fenwal DXT™, etc.). El conjunto de datos 303 puede incluir una farmacoteca creada por un usuario, recuperada de una colección, especificada por una empresa farmacéutica, etc., y que se ha cargado en el sistema de gestión de datos 110.
En el bloque 304, se crea una regla de distribución para el conjunto de datos 303. Por ejemplo, la regla de distribución puede especificar dónde y/o cómo deben distribuirse los datos (p. ej., a todas las bombas en todas las ubicaciones, a las bombas en una ubicación específica, a una o varias bombas específicas, etc.). Las FIGS. 4A-4I representan interfaces de usuario de ejemplo para la creación de reglas de distribución.
La FIG. 4A muestra un ejemplo de interfaz de usuario 400 del sistema de gestión de datos desde el que un usuario puede seleccionar un conjunto de datos nuevo (p. ej., JimsDataset-000) de una lista de conjuntos de datos disponibles. En la interfaz 410 de ejemplo de la FIG. 4B se muestra una regla de distribución existente para el conjunto de datos seleccionado. Como se muestra en la interfaz 420 de ejemplo de la FIG. 4C, al seleccionar "Por hospital" en el menú desplegable "Crear regla", se crea una regla de conjunto de datos para un hospital en particular. Como alternativa, se puede crear una regla de distribución para toda una organización. Como se ilustra en el ejemplo de la FIG. 4D, pueden seleccionarse uno o más hospitales (p. ej., el hospital de Lake Zurich) desde la interfaz 430 para la distribución del conjunto de datos nuevo, y al seleccionar el botón o una opción similar de creación se genera la regla 305 correspondiente. La regla creada puede revisarse y confirmarse a través de la interfaz 440 de ejemplo de la FIG. 4E. Como se ilustra en la interfaz 410 actualizada de ejemplo de la FIG. 4F, se ha añadido una nueva regla de distribución a la lista con la regla de distribución existente.
La regla 305 es almacenada por el sistema de gestión de datos con una o más reglas de distribución 306 de conjuntos de datos. Se proporciona un conjunto de datos objetivo 307 de acuerdo con la regla 305 en las reglas de distribución 306 de conjuntos de datos. La interfaz 450 de ejemplo de la FIG. 4G representa una vista de ejemplo de qué dispositivos (p. ej., bombas) tienen pendiente la distribución del conjunto de datos nuevo de acuerdo con la regla de distribución 305 seleccionada. Como se muestra en la vista 460 de ejemplo de la FIG. 4H, dos bombas han descargado el conjunto de datos 307 de acuerdo con la regla 305. Como se muestra en la vista 470 de ejemplo de la FIG. 4I, una distribución se ha completado. Por tanto, un usuario puede supervisar la distribución e instalación de un conjunto de datos en uno o más dispositivos sanitarios de acuerdo con una regla de distribución a través de un sistema de gestión de datos.
En el bloque 308, el conjunto de datos objetivo 307 desencadena una solicitud de una versión del conjunto de datos actual desde el dispositivo sanitario 310 (p. ej., una bomba de infusión, un dispositivo de aféresis, etc.). En el ejemplo de la FIG. 3, el dispositivo sanitario 310 es una bomba que está infundiendo a un paciente. La bomba 310 transmite la versión 309 de su conjunto de datos actual, que se procesa y compara con el conjunto de datos objetivo 307 (bloque 308). El conjunto de datos objetivo 307 también se envía al bloque 312, que lee el conjunto de datos objetivo y, en el bloque 314, envía el conjunto de datos objetivo 307 a la bomba 310. La FIG. 5A representa una interfaz de usuario 500 de ejemplo para una bomba que está infundiendo y que ha recibido el conjunto de datos objetivo 307 de acuerdo con la nueva regla de distribución 305 del conjunto de datos.
La bomba 310 recibe el conjunto de datos objetivo 307 y activa una configuración con un conjunto de datos nuevo 311 basado en el conjunto de datos objetivo 307 recibido. En el ejemplo de la FIG. 3, la bomba 310 está infundiendo cuando recibe el conjunto de datos objetivo 307. En el bloque 316, el conjunto de datos nuevo 311 se programa con respecto a la bomba 310 mientras la bomba 310 está infundiendo. La FIG. 5B representa una interfaz de usuario 550 de ejemplo que muestra que la bomba 310 recibe y programa el conjunto de datos nuevo 311 mientras la bomba 310 está infundiendo.
En el bloque 318, la programación satisfactoria de la bomba 310 con el conjunto de datos nuevo 311 genera una notificación 313. La notificación 313 puede incluir una notificación 313 acústica (p. ej., un sonido, una alarma, etc.), visual (p. ej., un indicador luminoso, un destello de luz, etc.) y/o electrónica (p. ej., una entrada de registro, un activador de programa, un mensaje, etc.) de la programación de nuevos conjuntos de datos. La notificación 313 puede proporcionarse a un técnico, tal como un personal de enfermería 320, y/o al sistema de gestión de datos 110 y/o a otro dispositivo informático, por ejemplo.
En el bloque 322, se comprueba la bomba 310 para determinar si se ha completado la infusión. Si la bomba 310 sigue infundiendo, el sistema de bombeo 310 espera a que finalice la infusión antes de continuar. Si la infusión está completa, entonces, en el bloque 324, la bomba 310 se apaga. La bomba 310 puede apagarse manualmente (p. ej., por el técnico 320) y/o apagarse automáticamente cuando así lo desencadene la programación del conjunto de datos nuevo y la finalización de la infusión, por ejemplo. En el bloque 326, la bomba 310 se enciende para activar el conjunto de datos nuevo en la bomba 310. La bomba 310 puede encenderse manualmente (p. ej., por el técnico 320) y/o activarse/reiniciarse automáticamente en función del conjunto de datos nuevo. La FIG. 5C representa una interfaz de usuario 570 de ejemplo que muestra una infusión completada con un conjunto de datos nuevo en la bomba 310 tras un apagado y encendido de la bomba 310. El proceso 300 de ejemplo puede repetirse para cada uno de una pluralidad de dispositivos sanitarios en comunicación con el sistema de gestión de datos 110.
En ciertos ejemplos, como en el bloque 308, el sistema de gestión de datos 110 compara una versión actual de un conjunto de datos de una bomba con una versión del conjunto de datos objetivo (p. ej., la versión del conjunto de datos que se distribuirá a la bomba). El sistema de gestión de datos 110 puede utilizar un algoritmo tal como el siguiente ejemplo para evaluar las versiones del conjunto de datos:
En la tabla de reglas anterior, un 1 equivale a un identificador único universal (UUID) (p. ej., un valor que representa la versión del conjunto de datos), y un 0 equivale a un UUID con valor nulo o cero (UUID-NULO). De acuerdo con las reglas anteriores, la bomba 310 descargará el conjunto de datos nuevo del sistema de gestión de datos 110 si el Objetivo no es igual a 0 (p. ej., no es un UUID-NULO).
Por tanto, si la bomba no tiene un conjunto de datos activo o programado y no se descarga ningún conjunto de datos, entonces se descargará el conjunto de datos objetivo. Si la bomba no tiene un conjunto de datos activo o programado, y se ha descargado un conjunto de datos, pero no tiene la misma versión que la del objetivo, entonces se descargará el conjunto de datos objetivo. Si la bomba tiene un conjunto de datos programado, pero no activo, y no se ha descargado ningún conjunto de datos, se descargará el conjunto de datos objetivo si el conjunto de datos programado no tiene la misma versión que la del objetivo. Si la bomba no tiene un conjunto de datos activo, pero tiene un conjunto de datos programado y descargado, se descargará el conjunto de datos objetivo si la versión del conjunto de datos descargado no es la misma que la del destino. Si la bomba tiene un conjunto de datos activo, pero no hay ninguno programado o descargado, entonces se descargará el conjunto de datos objetivo si el conjunto de datos activo no es igual al objetivo. Si la bomba tiene un conjunto de datos activo y se descarga uno, pero no hay ninguno programado, entonces se descargará el conjunto de datos objetivo si el conjunto de datos descargado es de una versión diferente a la del conjunto de datos objetivo. Si la bomba tiene un conjunto de datos activo y un conjunto de datos programado, pero no tiene ningún conjunto de datos descargado, entonces se descargará el conjunto de datos objetivo si la versión del conjunto de datos objetivo no es igual a la versión del conjunto de datos activo. Si la bomba tiene un conjunto de datos activo, un conjunto de datos programado y un conjunto de datos descargado, entonces la bomba descargará el conjunto de datos objetivo si la versión del conjunto de datos objetivo no es igual a la versión del conjunto de datos descargado. Por tanto, la bomba y/o el sistema de gestión de datos evalúa la información sobre la versión del conjunto de datos basándose en un UUID que representa la versión.
En ciertos ejemplos, tal como en la tabla anterior, una bomba puede tener un conjunto de datos en funcionamiento (p. ej., activo), un conjunto de datos que se ha programado en la bomba, pero que aún no se ha activado, y/o un conjunto de datos que se ha descargado, pero que aún no se ha programado en la bomba. Evaluando si el conjunto de datos objetivo es de una versión diferente a la del conjunto o conjuntos de datos actuales de la bomba, la bomba y/o el sistema de gestión de datos pueden evaluar si descargar el conjunto de datos objetivo, que a continuación se programará y activará en la bomba como se ha descrito anteriormente con respecto a las FIGS. 2-3.
Por tanto, ciertos ejemplos permiten la distribución de un conjunto de datos (p. ej., una farmacoteca y/u otras instrucciones) a un dispositivo sanitario sin afectar a la actividad en curso del dispositivo. La FIG. 6 representa una interfaz 600 de ejemplo que muestra una pluralidad de dispositivos sanitarios (p. ej., bombas, etc.) y su conjunto de datos activo asociado, su conjunto de datos objetivo, etc., con fines de identificación, evaluación y configuración.
La FIG. 7 ilustra un diagrama de bloques de un sistema de monitorización y control 700 de dispositivos sanitarios de ejemplo. El control 700 de un dispositivo sanitario de ejemplo incluye un evaluador de versión 710, un descargador 720, un programador 730, un evaluador de estado 740 y un controlador 750. El evaluador de versión 710 recibe información relativa a un conjunto de datos objetivo y compara la información de versión del conjunto de datos objetivo con la información de versión de uno o más conjuntos de datos que se encuentran en el dispositivo sanitario (véase, la tabla de toma de decisiones de ejemplo descrita anteriormente y el proceso 300 de ejemplo de la FIG. 3).
Si el evaluador de versión 710 determina que el conjunto de datos objetivo es de una versión diferente a la de un conjunto de datos actualmente activo, programado y/o descargado en el dispositivo sanitario 700, entonces el evaluador de versión activa el descargador 730 para descargar el conjunto de datos objetivo. Una vez descargado el conjunto de datos por el descargador 720 (p. ej., a través de WiFi™, Bluetooth™, comunicación de campo cercano (NFC), transferencia de datos por cable, etc.), el descargador 720 activa el programador 730 para programar el dispositivo sanitario con el conjunto de datos nuevo. En ciertos ejemplos, el dispositivo sanitario puede seguir operando con un conjunto de datos activo mientras se programa con el conjunto de datos nuevo. Es posible que el conjunto de datos programado no se active hasta que se desconecte la alimentación y/o se reinicie el dispositivo sanitario, por ejemplo.
Una vez que el dispositivo sanitario haya sido programado con el conjunto de datos descargado por el programador 730, el programador 730 activa el evaluador de estado 740 para evaluar un estado de operación actual del dispositivo sanitario. Si el dispositivo sanitario está operando con respecto a un paciente u otro sujeto (p. ej., un donante de sangre, etc.), entonces el evaluador de estado 740 mantendrá la situación actual hasta que la operación actual (p. ej., la infusión, la recogida, etc.) del dispositivo sanitario se haya completado. Una vez que el dispositivo sanitario está inactivo, el evaluador de estado 740 activa el controlador 750. El controlador 750 puede solicitar y/o hacer que un operador apague y encienda el dispositivo sanitario, y/o el controlador 750 puede, tras un intervalo de inactividad definido, reiniciar automáticamente el dispositivo sanitario (p. ej., con un aviso y la posibilidad de anulación por parte del usuario) para activar el conjunto de datos nuevo programado.
Por tanto, una bomba puede estar infundiendo un medicamento a un paciente mientras, en segundo plano, se envía a la bomba una nueva farmacoteca que se convertirá en la nueva farmacoteca una vez que se complete la infusión actual (y se desconecte la alimentación de la bomba). La operación en curso de la bomba no se interrumpe, y el conjunto de datos nuevo está listo para la operación de la bomba antes de la siguiente operación (p. ej., la siguiente infusión, la siguiente recogida, etc.). Una vez identificada, creada y/o recibida una regla de distribución del conjunto de datos, el sistema de gestión de datos se comunica con el control de la bomba para enviar información al dispositivo sanitario según lo especificado en la regla. Cuando la bomba está infundiendo y ha recibido una nueva farmacoteca, aparece un icono y/u otro indicador en la interfaz de la bomba (véase, p. ej., la FIG. 5B) para notificar a un usuario que la nueva farmacoteca está disponible. No se hace nada que afecte a una operación en curso o ponga en peligro a un paciente actual, pero, una vez que la bomba se ha parado, se pide al usuario que la apague y la encienda (y/o la alimentación se reinicia automáticamente) para activar la farmacoteca y los parámetros asociados para usar la bomba.
La FIG. 8 es un diagrama de bloques de una plataforma de procesador 800 de ejemplo capaz de ejecutar las instrucciones de las FIGS. 2 y 3 para implementar los sistemas e interfaces de ejemplo de las FIGS. 1, 4A-4I, 5A-5C y 6. La plataforma de procesador 800 puede ser, por ejemplo, un servidor, un ordenador personal, un dispositivo móvil (p. ej., un teléfono móvil, un teléfono inteligente, una tableta, como un iPadTM), un asistente digital personal (PDA), un dispositivo de Internet, un reproductor de DVD, un reproductor de CD, un grabador de vídeo digital, un reproductor Blu-ray, una consola de juegos, una grabadora de vídeo personal, un descodificador o cualquier otro tipo de dispositivo informático.
La plataforma de procesador 800 del ejemplo ilustrado incluye un procesador 812. El procesador 812 del ejemplo ilustrado es hardware. Por ejemplo, el procesador 812 puede ser implementado por uno o más circuitos integrados, circuitos lógicos, microprocesadores o controladores de cualquier familia o fabricante que se desee. En el ejemplo ilustrado, el procesador 812 está estructurado para incluir el evaluador de versión 710 de ejemplo, el descargador 720 de ejemplo, el programador 730 de ejemplo, el evaluador de estado 740 de ejemplo y controlador 750 de ejemplo del sistema de control 700 de dispositivos sanitarios de ejemplo.
El procesador 812 del ejemplo ilustrado incluye una memoria local 813 (p. ej., un caché). El procesador 812 del ejemplo ilustrado está en comunicación con una memoria principal que incluye una memoria volátil 814 y una memoria no volátil 816 a través de un bus 818. La memoria volátil 814 puede implementarse mediante una memoria dinámica de acceso aleatorio con interfaz síncrona (SDRAM), una memoria dinámica de acceso aleatorio (DRAM), una memoria dinámica de acceso aleatorio RAMBUS (RDRAM) y/o cualquier otro tipo de dispositivo de memoria de acceso aleatorio. La memoria no volátil 816 puede implementarse mediante una memoria flash y/o cualquier otro tipo de dispositivo de memoria deseado. El acceso a la memoria principal 814, 816 está controlado por un controlador de memoria.
La plataforma de procesador 800 del ejemplo ilustrado también incluye un circuito de interfaz 820. El circuito de interfaz 820 puede implementarse mediante cualquier tipo de estándar de interfaz, tal como una interfaz Ethernet, un bus serie universal (USB) y/o una interfaz PCI Express.
En el ejemplo ilustrado, uno o más dispositivos de entrada 822 están conectados al circuito de interfaz 820. El dispositivo o dispositivos de entrada 822 permiten al usuario introducir datos y comandos en el procesador 812. El dispositivo o dispositivos de entrada pueden ser, por ejemplo, un sensor de audio, un micrófono, una cámara (fotográfica o de vídeo), un teclado, un botón, un ratón, una pantalla táctil, una pista de contacto, una bola de desplazamiento, un sistema de reconocimiento de voz y/o punto isoeléctrico.
Uno o más dispositivos de salida 824 también están conectados al circuito de interfaz 820 del ejemplo ilustrado. Los dispositivos de salida 824 pueden ser implementados, por ejemplo, mediante dispositivos de visualización (p. ej., un diodo de emisión de luz [LED], un diodo orgánico de emisión de luz [OLED], una pantalla de cristal líquido, una pantalla de tubo de rayos catódicos [TRC], una pantalla táctil, un dispositivo de salida táctil, una impresora y/o altavoces). El circuito de interfaz 820 del ejemplo ilustrado, por tanto, incluye normalmente una tarjeta controladora de gráficos, un chip controlador de gráficos o un procesador controlador de gráficos.
El circuito de interfaz 820 del ejemplo ilustrado incluye también un dispositivo de comunicación tal como un transmisor, un receptor, un transceptor, un módem y/o una tarjeta de interfaz de red para facilitar el intercambio de datos con máquinas externas (p. ej., dispositivos informáticos de cualquier tipo) a través de una red 826 (p. ej., una conexión Ethernet, una línea de abonado digital [DSL], una línea telefónica, un cable coaxial, un sistema de telefonía móvil, etc.).
La plataforma de procesador 800 del ejemplo ilustrado también incluye uno o más dispositivos de almacenamiento masivo 828 para almacenar software y/o datos. Entre los ejemplos de dispositivos de almacenamiento masivo 828 se incluyen unidades de disquete, unidades de disco duro, unidades de disco compacto, unidades de disco Blu-ray, sistemas RAID y unidades de disco versátil digital (DVD).
Las instrucciones codificadas 832 que representan los diagramas de flujo de las FIGS. 2-3 pueden almacenarse en el dispositivo de almacenamiento masivo 828, en la memoria volátil 814, en la memoria no volátil 816 y/o en un medio de almacenamiento extraíble legible por ordenador tangible, tal como un CD o DVD.
De lo anterior, se apreciará que se han divulgado ejemplos que permiten que la farmacoteca y/u otro(s) conjunto(s) de datos se proporcione(n) dinámicamente a los dispositivos sanitarios y se actualice(n) en ellos sin afectar al funcionamiento del (de los) producto(s) sanitario(s) y/o que comprenda(n) la seguridad y/o el tratamiento del paciente. Al transferir y actualizar un dispositivo sanitario en segundo plano durante la operación del dispositivo, pueden reducirse y/o minimizarse el tiempo de inactividad, la ineficacia y la imprecisión cuando el dispositivo se reinicia para aceptar/activar los cambios una vez que el dispositivo vuelve a estar inactivo tras completar un procedimiento, por ejemplo.
Por tanto, ciertos ejemplos proporcionan un mecanismo de seguimiento para determinar qué conjunto de datos se supone que está cargado en un dispositivo sanitario frente a qué conjunto de datos está realmente cargado en el dispositivo sanitario. Ciertos ejemplos proporcionan sistemas y métodos controlados por una regla organizada como una estructura de datos que existe como una transacción que proporciona no solo los datos en sí para leer/escribir, sino también transiciones a ciertas etapas o estados (p. ej., creado, iniciado/distribuido, en curso, luego pasar a completado/interrumpido, etc.). Una condición de vida o etapa de la transacción proporciona un estado basado en una ubicación cubierta por la regla.
Por ejemplo, un sistema puede incluir bombas de infusión en la ubicación A y en la ubicación B, pero puede que una regla solo cubra la ubicación A. La regla A desencadena entonces la recepción de información de estado solo para las bombas de la ubicación A.
Ciertos ejemplos proporcionan una conexión entre un dispositivo sanitario, una ubicación y una regla. Un sistema de gestión de dispositivos sanitarios recibe una regla e informa del estado basándose en la regla. El sistema sabe si una regla está asociada a un dispositivo/grupo de dispositivos en particular y determina qué dispositivo(s) se actualizará(n). El sistema envía datos y recibe información del estado y/o de otro tipo de acuerdo con la regla. Si la regla no se aplica a un dispositivo, entonces ese dispositivo no recibe la información del sistema.
En ciertos ejemplos, el envío de un fichero de datos a un dispositivo puede producirse en cualquier momento, aunque el dispositivo esté en uso (p. ej., si la bomba está infundiendo). Un estado o condición del conjunto de datos se considera para su descarga. Al encender el dispositivo se produce un cambio o conmutación en el conjunto de datos para hacer funcionar el dispositivo, y un conjunto de datos nuevo descargado se hace efectivo cuando el dispositivo sanitario (p. ej., la bomba de infusión, etc.) se reinicia (p. ej., se apaga/se enciende). En ciertos ejemplos, tras el reinicio, el usuario (p. ej., un personal de enfermería, un auxiliar, etc.) no tiene más remedio que reconocer el conjunto de datos nuevo o el dispositivo no funcionará. Por lo tanto, se puede aplicar la regla de datos nueva, ya que el usuario y la máquina no tienen más remedio que aceptar el conjunto de datos nuevo al reiniciar, por ejemplo.
En ciertos ejemplos, una farmacia controla el conjunto de datos y su distribución, y el usuario final (p. ej., un personal de enfermería, un auxiliar, etc.) no dispone de margen de decisión, sino que debe aceptar el conjunto de datos para seguir utilizando el dispositivo. El sistema de gestión de dispositivos envía un conjunto de datos, y un dispositivo receptor está configurado para aplicar el conjunto de datos nuevo en el siguiente reinicio. El conjunto de datos descargado se mantiene en un búfer de descarga, por ejemplo, y, una vez encendido el dispositivo, el dispositivo programa el conjunto de datos en la memoria activa. A continuación, se informa al usuario del conjunto de datos nuevo y se le dan instrucciones para usar el dispositivo o apagarlo, pero no puede volver a una versión anterior del conjunto de datos. En ciertos ejemplos, el dispositivo no se ve obligado a reiniciarse por motivos de seguridad (p. ej., al bombear medicamentos de soporte vital, etc.), por lo que el dispositivo y el conjunto de datos nuevo pueden retrasarse o demorarse a la espera de un próximo reinicio.
Ciertos ejemplos facilitan la actualización automática de la regla a lo largo del tiempo, a medida que el sistema de gestión de dispositivos recopila datos y el estado de los dispositivos sanitarios asociados. Un tercero, tal como un farmacéutico, proporciona un conjunto de datos nuevo y un conjunto de ubicaciones objetivo basados en los datos recopilados. Una vez que el conjunto de datos se ha programado en un dispositivo sanitario objetivo y el dispositivo se enciende de nuevo, la configuración/conjunto de datos nuevo debe aceptarse o el dispositivo se desactiva para impedir que un usuario utilice el dispositivo de un modo no previsto por el farmacéutico, por ejemplo.
En ciertos ejemplos, una instalación inicial de un conjunto de datos se produce cuando una ubicación (p. ej., un hospital, una clínica, una consulta de médica, etc.) no ha utilizado previamente un dispositivo sanitario y/o una farmacoteca asociada. Tras la instalación, las actualizaciones pueden ser periódicas y/o aperiódicas (p. ej., una vez a la semana, una vez al mes, al activarse y/o a demanda, etc.). Las actualizaciones pueden ser más frecuentes en una ubicación que nunca ha utilizado un conjunto de datos concreto (p. ej., una farmacoteca, etc.) con anterioridad y con menor frecuencia si la ubicación ha utilizado una versión anterior del conjunto de datos con el mismo proveedor o con otro diferente y comprende la configuración, las preferencias, etc., para el conjunto de datos, por ejemplo.
Los cambios pueden producirse por diversas razones, como los formularios de medicamentos, los ensayos farmacológicos, los cambios de límite, etc. (p. ej., produciéndose cada 6-12 meses, etc.). El farmacéutico y/u otra persona encargada de la entrega de los conjuntos de datos puede interrumpir la regla, anular la regla, etc. Un cambio crítico para la seguridad puede aplicarse lo antes posible, por ejemplo.
Por tanto, ciertos ejemplos proporcionan un sistema de extremo a extremo para la distribución y supervisión de conjuntos de datos a dispositivos sanitarios. El sistema de gestión de dispositivos sanitarios puede determinar qué conjunto de datos está siendo utilizado por cada dispositivo sanitario supervisado, así como el estado de los conjuntos de datos nuevos/actualizados descargados en el (los) dispositivo(s) médico(s) supervisado(s). El seguimiento puede facilitar la investigación para determinar por qué no se han actualizado determinados dispositivos (p. ej., acaparados por el personal de enfermería, no enchufados o sin batería, desaparecidos, etc.) para facilitar un seguimiento, una resolución de problemas, un mantenimiento y un control de calidad mejorados de los recursos, por ejemplo.
Ciertos ejemplos proporcionan un método implementado por ordenador para la gestión de dispositivos sanitarios. El método de ejemplo incluye la comparación de una primera identificación de un primer conjunto de datos con una segunda identificación de un segundo conjunto de datos en un dispositivo sanitario; cuando la primera identificación no coincide con la segunda, se activa la descarga del segundo conjunto de datos al dispositivo sanitario; se determina el estado de operación del dispositivo sanitario; cuando el estado de operación indica que el dispositivo sanitario está inactivo, se desencadena la activación del segundo conjunto de datos en lugar del primero en el dispositivo sanitario; y se facilita la operación del dispositivo sanitario de acuerdo con el segundo conjunto de datos.
En ciertos ejemplos, el método incluye, además, la programación del dispositivo sanitario con el segundo conjunto de datos. En ciertos ejemplos, el método incluye, además, la activación de una notificación tras la programación del dispositivo sanitario con el segundo conjunto de datos. En ciertos ejemplos, desencadenar la activación del segundo conjunto de datos incluye el apagado y encendido del dispositivo sanitario. En ciertos ejemplos, el método incluye, además, la creación de una regla de distribución para distribuir el segundo conjunto de datos a uno o más dispositivos sanitarios. En ciertos ejemplos, el dispositivo sanitario incluye una bomba. En ciertos ejemplos, el segundo conjunto de datos incluye una farmacoteca.
Ciertos ejemplos proporcionan un medio de almacenamiento tangible legible por ordenador que incluye código de programa para su ejecución por un procesador. El código de programa, cuando se ejecuta, aplica un método para la gestión de dispositivos sanitarios. El método de ejemplo incluye la comparación de una primera identificación de un primer conjunto de datos con una segunda identificación de un segundo conjunto de datos en un dispositivo sanitario; cuando la primera identificación no coincide con la segunda, se activa la descarga del segundo conjunto de datos al dispositivo sanitario; se determina el estado de operación del dispositivo sanitario; cuando el estado de operación indica que el dispositivo sanitario está inactivo, se desencadena la activación del segundo conjunto de datos en lugar del primero en el dispositivo sanitario; y se facilita la operación del dispositivo sanitario de acuerdo con el segundo conjunto de datos.
En ciertos ejemplos, el método incluye, además, la programación del dispositivo sanitario con el segundo conjunto de datos. En ciertos ejemplos, el método incluye, además, la activación de una notificación tras la programación del dispositivo sanitario con el segundo conjunto de datos. En ciertos ejemplos, desencadenar la activación del segundo conjunto de datos incluye el apagado y encendido del dispositivo sanitario. En ciertos ejemplos, el método incluye, además, la creación de una regla de distribución para distribuir el segundo conjunto de datos a uno o más dispositivos sanitarios. En ciertos ejemplos, el dispositivo sanitario incluye una bomba. En ciertos ejemplos, el segundo conjunto de datos incluye una farmacoteca.
Ciertos ejemplos proporcionan un sistema que incluye un procesador y una memoria particularmente configurados para implementar al menos un evaluador de versión, un descargador, un evaluador de estado y un controlador. El evaluador de versión de ejemplo está configurado para comparar una primera identificación de un primer conjunto de datos con una segunda identificación de un segundo conjunto de datos en un dispositivo sanitario. El descargador de ejemplo está configurado para, cuando la primera identificación no coincide con la segunda, activar la descarga del segundo conjunto de datos al dispositivo sanitario. El evaluador de estado de ejemplo está configurado para determinar un estado de operación del dispositivo sanitario. El controlador de ejemplo está configurado para, cuando el estado de operación indica que el dispositivo sanitario está inactivo, activar el segundo conjunto de datos en lugar del primero en el dispositivo sanitario y facilitar la operación del dispositivo sanitario de acuerdo con el segundo conjunto de datos.
En ciertos ejemplos, el sistema incluye, además, un programador configurado para programar el dispositivo sanitario con el segundo conjunto de datos. En ciertos ejemplos, el programador está configurado, además, para activar una notificación tras la programación del dispositivo sanitario con el segundo conjunto de datos. En ciertos ejemplos, desencadenar la activación del segundo conjunto de datos incluye el apagado y encendido del dispositivo sanitario. En ciertos ejemplos, se crea una regla de distribución para distribuir el segundo conjunto de datos a uno o más dispositivos sanitarios. En ciertos ejemplos, el dispositivo sanitario se desactiva si el segundo conjunto de datos no se activa tras el apagado y encendido del dispositivo sanitario. En ciertos ejemplos, el dispositivo sanitario incluye una bomba, y en donde el segundo conjunto de datos incluye una farmacoteca.

Claims (17)

REIVINDICACIONES
1. Un método implementado por ordenador para la gestión de dispositivos sanitarios, comprendiendo dicho método:
crear una regla de distribución de conjuntos de datos asociada a un sistema de gestión de datos de dispositivo sanitario, en donde la regla de distribución de conjuntos de datos comprende (a) un primer identificador único representativo de un conjunto de datos activo en el dispositivo sanitario, en donde el conjunto de datos activo incluye el primer identificador único asociado a un primer archivo de conjunto de datos para su uso por el dispositivo sanitario, (b) un segundo identificador único representativo de un conjunto de datos programado en el dispositivo sanitario, en donde el conjunto de datos programado incluye el segundo identificador único asociado a un segundo archivo de conjunto de datos que está siendo programado, pero no está en uso, por el dispositivo sanitario, y (c) un tercer identificador único representativo de un conjunto de datos descargado en el dispositivo sanitario, en donde el conjunto de datos descargado incluye el tercer identificador único asociado a un tercer archivo de conjunto de datos descargado del sistema de gestión de datos de dispositivos sanitarios, pero no programado en el dispositivo sanitario, y en donde la regla de distribución de conjuntos de datos comprende además un cuarto identificador único representativo de un conjunto de datos objetivo, en donde el conjunto de datos objetivo incluye el cuarto identificador único asociado a una regla de conjunto de datos programada para la entrega de un archivo de conjunto de datos correspondiente al dispositivo sanitario durante la distribución del conjunto de datos, en donde al menos uno del conjunto de datos activo, el conjunto de datos programado, el conjunto de datos descargado y el conjunto de datos objetivo comprenden uno o más parámetros para configurar el dispositivo sanitario para administrar una inyección a un sujeto;
comparar, por medio del sistema de gestión de datos de dispositivo sanitario, el primer identificador único, el segundo identificador único y el tercer identificador único con el cuarto identificador único en el dispositivo sanitario y/o en el sistema de gestión de datos de dispositivo sanitario;
en respuesta a la determinación, por medio de un evaluador de versión, de que el conjunto de datos objetivo es de una versión diferente a la de un conjunto de datos actualmente activo, programado o descargado en el dispositivo sanitario, activar, por medio de un descargador, la descarga del conjunto de datos objetivo en el dispositivo sanitario, en donde el sistema de gestión de datos de dispositivo sanitario evalúa la información de la versión del conjunto de datos basándose en un identificador único universal, UUID, que representa la versión;
en respuesta a la descarga del conjunto de datos objetivo en el dispositivo sanitario, programar, por medio de un programador, el dispositivo sanitario con el conjunto de datos objetivo descargado, en donde el dispositivo sanitario sigue operando con el conjunto de datos activo mientras se programa con el conjunto de datos objetivo y en donde la operación del dispositivo sanitario y la distribución del conjunto de datos se realizan simultáneamente sin afectar a la actividad en curso del dispositivo sanitario;
en respuesta a la programación del conjunto de datos descargado, determinar, por medio de un evaluador de estado, un estado de operación del dispositivo sanitario:
en respuesta al estado de operación indicando que el dispositivo sanitario está operando actualmente con respecto al sujeto, mantener una situación actual hasta que se haya completado la operación actual del dispositivo sanitario;
en respuesta al estado de operación indicando que el dispositivo sanitario está inactivo, desencadenar la activación del conjunto de datos objetivo en el dispositivo sanitario; y
administrar una inyección al sujeto mediante el dispositivo sanitario de acuerdo con el conjunto de datos objetivo.
2. El método de la reivindicación 1, que incluye, además, la activación de una notificación tras la programación del dispositivo sanitario con el conjunto de datos objetivo.
3. El método de la reivindicación 1, en donde desencadenar la activación del conjunto de datos objetivo incluye el apagado y encendido del dispositivo sanitario.
4. El método de la reivindicación 1, en donde el dispositivo sanitario incluye una bomba.
5. El método de la reivindicación 4, en donde el conjunto de datos objetivo incluye una farmacoteca.
6. El método de la reivindicación 5, en donde el cuarto identificador único es un identificador único universal, UUID, que representa una versión de la farmacoteca.
7. Un medio tangible de almacenamiento legible por ordenador que comprende código de programa que, cuando se ejecuta, hace que un procesador implemente un método para la gestión de dispositivo sanitario, comprendiendo dicho método:
crear una regla de distribución de conjuntos de datos asociada a un sistema de gestión de datos de dispositivo sanitario, en donde la regla de distribución de conjuntos de datos comprende (a) un primer identificador único representativo de un conjunto de datos activo en el dispositivo sanitario, en donde el conjunto de datos activo incluye el primer identificador único asociado a un primer archivo de conjunto de datos para su uso por el dispositivo sanitario, (b) un segundo identificador único representativo de un conjunto de datos programado en el dispositivo sanitario, en donde el conjunto de datos programado incluye el segundo identificador único asociado a un segundo archivo de conjunto de datos que está siendo programado, pero no está en uso, por el dispositivo sanitario, y (c) un tercer identificador único representativo de un conjunto de datos descargado en el dispositivo sanitario, en donde el conjunto de datos descargado incluye el tercer identificador único asociado a un tercer archivo de conjunto de datos descargado del sistema de gestión de datos de dispositivo sanitario, pero no programado en el dispositivo sanitario, y en donde la regla de distribución de conjuntos de datos comprende además un cuarto identificador único representativo de un conjunto de datos objetivo, en donde el conjunto de datos objetivo incluye el cuarto identificador único asociado a una regla de conjunto de datos programada para la entrega de un archivo de conjunto de datos correspondiente al dispositivo sanitario durante la distribución del conjunto de datos, en donde al menos uno del conjunto de datos activo, el conjunto de datos programado, el conjunto de datos descargado y el conjunto de datos objetivo comprenden uno o más parámetros para configurar el dispositivo sanitario para administrar una inyección a un sujeto;
comparar, por medio del sistema de gestión de datos de dispositivo sanitario, el primer identificador único, el segundo identificador único y el tercer identificador único con el cuarto identificador único en el dispositivo sanitario y/o en el sistema de gestión de datos de dispositivo sanitario;
en respuesta a la determinación, por medio de un evaluador de versión, de que el conjunto de datos objetivo es de una versión diferente a la de un conjunto de datos actualmente activo, programado o descargado en el dispositivo sanitario, activar, por medio de un descargador, la descarga del conjunto de datos objetivo en el dispositivo sanitario, en donde el sistema de gestión de datos de dispositivo sanitario evalúa la información de la versión del conjunto de datos basándose en un identificador único universal, UUID, que representa la versión;
en respuesta a la descarga del conjunto de datos objetivo en el dispositivo sanitario, programar, por medio de un programador, el dispositivo sanitario con el conjunto de datos objetivo descargado, en donde el dispositivo sanitario sigue operando con el conjunto de datos activo mientras se programa con el conjunto de datos objetivo y en donde la operación del dispositivo sanitario y la distribución del conjunto de datos se realizan simultáneamente sin afectar a la actividad en curso del dispositivo sanitario;
en respuesta a la programación del conjunto de datos descargado, determinar, por medio de un evaluador de estado, un estado de operación del dispositivo sanitario:
en respuesta al estado de operación indicando que el dispositivo sanitario está operando actualmente con respecto al sujeto, mantener una situación actual hasta que se haya completado la operación actual del dispositivo sanitario;
en respuesta al estado de operación indicando que el dispositivo sanitario está inactivo, desencadenar la activación del conjunto de datos objetivo en el dispositivo sanitario; y
administrar una inyección al sujeto mediante el dispositivo sanitario de acuerdo con el conjunto de datos objetivo.
8. El medio de almacenamiento legible por ordenador de la reivindicación 7, en donde el método incluye, además, la activación de una notificación tras la programación del dispositivo sanitario con el conjunto de datos objetivo.
9. El medio de almacenamiento legible por ordenador de la reivindicación 7, en donde desencadenar la activación del conjunto de datos objetivo incluye el apagado y encendido del dispositivo sanitario.
10. El medio de almacenamiento legible por ordenador de la reivindicación 7, en donde el dispositivo sanitario incluye una bomba.
11. El medio de almacenamiento legible por ordenador de la reivindicación 10, en donde el conjunto de datos objetivo incluye una farmacoteca.
12. El medio de almacenamiento legible por ordenador de la reivindicación 11, en donde el cuarto identificador único es un identificador único universal, UUID, que representa una versión de la farmacoteca.
13. Un sistema que comprende:
un procesador y una memoria configurados para implementar al menos:
un sistema de gestión de datos de dispositivo sanitario para gestionar al menos un dispositivo sanitario que tiene una regla de distribución de conjuntos de datos que comprende un primer identificador único representativo de un conjunto de datos activo, en donde el conjunto de datos activo incluye el primer identificador único asociado a un primer archivo de conjunto de datos para su uso por el dispositivo sanitario, un segundo identificador único representativo de un conjunto de datos programado, en donde el conjunto de datos programado incluye el segundo identificador único asociado a un segundo archivo de conjunto de datos que está siendo programado, pero no está en uso, por el dispositivo sanitario, un tercer identificador único representativo de un conjunto de datos descargado, en donde el conjunto de datos descargado incluye el tercer identificador único asociado a un tercer archivo de conjunto de datos descargado del sistema de gestión de datos de dispositivo sanitario, pero no programado en el dispositivo sanitario, y un cuarto identificador único representativo de un conjunto de datos objetivo, en donde el conjunto de datos objetivo incluye el cuarto identificador único asociado a una regla de conjunto de datos programada para la entrega de un archivo de conjunto de datos correspondiente al dispositivo sanitario durante la distribución del conjunto de datos;
un evaluador de versión configurado para comparar el primer identificador único, el segundo identificador único y el tercer identificador único con el cuarto identificador único en el dispositivo sanitario y/o el sistema de gestión de datos de dispositivo sanitario y determinar si el conjunto de datos objetivo es de una versión diferente a la de un conjunto de datos actualmente activo, programado y/o descargado en el dispositivo sanitario, en donde el evaluador de versión evalúa la información de la versión del conjunto de datos basándose en un identificador único universal, UUID, que representa la versión;
un descargador configurado para, en respuesta a que el conjunto de datos objetivo sea de una versión diferente, activar la descarga del conjunto de datos objetivo al dispositivo sanitario;
un evaluador de estado configurado para determinar un estado de operación del dispositivo sanitario; y un controlador configurado para,
en respuesta al estado de operación indicando que el dispositivo sanitario está operando actualmente con respecto a un sujeto, mantener una situación actual hasta que se haya completado una operación actual del dispositivo sanitario;
en respuesta al estado de operación que el dispositivo sanitario está inactivo, desencadenar la activación del conjunto de datos objetivo en el dispositivo sanitario y hacer que el dispositivo sanitario funcione con respecto al sujeto de acuerdo con el conjunto de datos objetivo.
14. El sistema de la reivindicación 13, en donde el programador está configurado, además, para activar una notificación tras la programación del dispositivo sanitario con el conjunto de datos objetivo.
15. El sistema de la reivindicación 13, en donde desencadenar la activación del conjunto de datos objetivo incluye el apagado y encendido del dispositivo sanitario.
16. El sistema de la reivindicación 13, en donde el dispositivo sanitario se desactiva si el conjunto de datos objetivo no se activa tras un apagado y encendido del dispositivo sanitario.
17. El sistema de la reivindicación 13, en donde el dispositivo sanitario incluye una bomba, y en donde el conjunto de datos objetivo incluye una farmacoteca.
ES16002492T 2015-11-25 2016-11-23 Data set distribution during medical device operation Active ES3013658T3 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US201562259942P 2015-11-25 2015-11-25

Publications (1)

Publication Number Publication Date
ES3013658T3 true ES3013658T3 (en) 2025-04-14

Family

ID=57406024

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16002492T Active ES3013658T3 (en) 2015-11-25 2016-11-23 Data set distribution during medical device operation

Country Status (4)

Country Link
US (1) US10740436B2 (es)
EP (1) EP3173957B1 (es)
ES (1) ES3013658T3 (es)
PL (1) PL3173957T3 (es)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8271106B2 (en) 2009-04-17 2012-09-18 Hospira, Inc. System and method for configuring a rule set for medical event management and responses
AU2012325937B2 (en) 2011-10-21 2018-03-01 Icu Medical, Inc. Medical device update system
AU2014225658B2 (en) 2013-03-06 2018-05-31 Icu Medical, Inc. Medical device communication method
JP6621748B2 (ja) 2013-08-30 2019-12-18 アイシーユー・メディカル・インコーポレーテッド 遠隔輸液レジメンを監視および管理するシステムならびに方法
US9662436B2 (en) 2013-09-20 2017-05-30 Icu Medical, Inc. Fail-safe drug infusion therapy system
US10311972B2 (en) 2013-11-11 2019-06-04 Icu Medical, Inc. Medical device system performance index
US10042986B2 (en) 2013-11-19 2018-08-07 Icu Medical, Inc. Infusion pump automation system and method
US9764082B2 (en) 2014-04-30 2017-09-19 Icu Medical, Inc. Patient care system with conditional alarm forwarding
US9724470B2 (en) 2014-06-16 2017-08-08 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
US9539383B2 (en) 2014-09-15 2017-01-10 Hospira, Inc. System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein
US20170147771A1 (en) 2015-11-25 2017-05-25 Fenwal, Inc. Medical device location authorization
EP3220297B1 (en) 2016-03-14 2019-06-26 Fenwal, Inc. Default data set distribution for medical devices
WO2018013842A1 (en) 2016-07-14 2018-01-18 Icu Medical, Inc. Multi-communication path selection and security system for a medical device
WO2019010127A1 (en) * 2017-07-03 2019-01-10 Stryker Corporation DATA COMMUNICATION SYSTEM
EP3791405A1 (en) * 2018-05-11 2021-03-17 Fresenius Vial SAS Distribution server for patient devices
NZ772135A (en) 2018-07-17 2022-11-25 Icu Medical Inc Systems and methods for facilitating clinical messaging in a network environment
EP3824386B1 (en) 2018-07-17 2024-02-21 ICU Medical, Inc. Updating infusion pump drug libraries and operational software in a networked environment
US10950339B2 (en) 2018-07-17 2021-03-16 Icu Medical, Inc. Converting pump messages in new pump protocol to standardized dataset messages
AU2019309766B2 (en) * 2018-07-26 2024-06-13 Icu Medical, Inc. Drug library management system
US10692595B2 (en) 2018-07-26 2020-06-23 Icu Medical, Inc. Drug library dynamic version management
EP3966992A4 (en) 2019-05-08 2023-06-21 ICU Medical, Inc. MEDICAL DEVICE MANAGEMENT BASED ON THRESHOLD DIGITAL SIGNATURES
US12002576B2 (en) 2019-07-15 2024-06-04 Carefusion 303, Inc. Systems and methods for updating firmware of medical devices while minimizing clinical impact
US11590057B2 (en) 2020-04-03 2023-02-28 Icu Medical, Inc. Systems, methods, and components for transferring medical fluids
WO2022006017A1 (en) 2020-07-02 2022-01-06 Icu Medical, Inc. Location-based reconfiguration of infusion pump settings
WO2022051230A1 (en) 2020-09-05 2022-03-10 Icu Medical, Inc. Identity-based secure medical device communications
US12505907B2 (en) * 2022-11-23 2025-12-23 Cerner Innovation, Inc. Systems and methods for infusion pump formulary validation
EP4708309A1 (de) * 2024-09-05 2026-03-11 B. Braun Melsungen AG Infusionspumpensystem und zugehöriges betriebsverfahren

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7645258B2 (en) * 1999-12-01 2010-01-12 B. Braun Medical, Inc. Patient medication IV delivery pump with wireless communication to a hospital information management system
US7860583B2 (en) * 2004-08-25 2010-12-28 Carefusion 303, Inc. System and method for dynamically adjusting patient therapy
US20040167465A1 (en) 2002-04-30 2004-08-26 Mihai Dan M. System and method for medical device authentication
US8234128B2 (en) * 2002-04-30 2012-07-31 Baxter International, Inc. System and method for verifying medical device operational parameters
US8359338B2 (en) * 2004-07-30 2013-01-22 Carefusion 303, Inc. System and method for managing medical databases for patient care devices
US20070168223A1 (en) * 2005-10-12 2007-07-19 Steven Lawrence Fors Configurable clinical information system and method of use
US20070233035A1 (en) * 2006-03-28 2007-10-04 Hospira, Inc. Medication administration and management system and method
US8423383B2 (en) 2006-08-15 2013-04-16 Jaxresearch Systems, Llc Contemporaneous, multi-physician, online consultation system
EP2544112A1 (en) * 2006-11-21 2013-01-09 Baxter International Inc. System and method for remote monitoring and/or management of infusion therapies
US20090094682A1 (en) 2007-10-05 2009-04-09 Peter Sage Methods and systems for user authorization
KR20100126598A (ko) 2008-04-01 2010-12-01 스미스 메디칼 에이에스디, 인크. 의료용 주입 펌프를 위한 보안 기능
US10089443B2 (en) * 2012-05-15 2018-10-02 Baxter International Inc. Home medical device systems and methods for therapy prescription and tracking, servicing and inventory
CA3114483A1 (en) * 2009-03-25 2010-09-30 Deka Products Limited Partnership Infusion pump methods and systems
US8726266B2 (en) * 2010-05-24 2014-05-13 Abbott Diabetes Care Inc. Method and system for updating a medical device
CA2839443A1 (en) * 2011-06-20 2012-12-27 Renaudia Medical, Llc Distributed medication delivery system and method having autonomous delivery devices
AU2012325937B2 (en) * 2011-10-21 2018-03-01 Icu Medical, Inc. Medical device update system
US9996681B2 (en) * 2012-05-18 2018-06-12 Carefusion 303, Inc. Mobile device access for medical devices
US9886550B2 (en) 2012-06-06 2018-02-06 Zyno Medical, Llc Medical pump with operator-authorization awareness
US9858630B2 (en) * 2012-09-28 2018-01-02 Cerner Innovation, Inc. Automated workflow access based on clinical user role and location
CN112435724A (zh) * 2013-02-27 2021-03-02 费森尤斯维尔公司 用于将操作数据传输至健康护理环境内的医疗设备的方法
US9596224B2 (en) 2013-04-05 2017-03-14 Nuvectra Corporation Systems, devices, components and methods for communicating with an IMD using a portable electronic device and a mobile computing device
US10042986B2 (en) * 2013-11-19 2018-08-07 Icu Medical, Inc. Infusion pump automation system and method
US10025909B2 (en) * 2014-08-04 2018-07-17 Ivenix, Inc. Medical devices and configuration update management
US9539383B2 (en) * 2014-09-15 2017-01-10 Hospira, Inc. System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein

Also Published As

Publication number Publication date
US10740436B2 (en) 2020-08-11
EP3173957C0 (en) 2025-01-01
US20170147761A1 (en) 2017-05-25
PL3173957T3 (pl) 2025-05-26
EP3173957A1 (en) 2017-05-31
EP3173957B1 (en) 2025-01-01

Similar Documents

Publication Publication Date Title
ES3013658T3 (en) Data set distribution during medical device operation
JP6972077B2 (ja) 構成可能閉ループ送達速度キャッチアップを有する注入システムおよびポンプ
US11475992B2 (en) System and method of synchronizing medical device databases
US11322238B2 (en) Default data set distribution for medical devices
ES2845725T3 (es) Sistema y método de bomba de infusión con capacidad de fuente de editor de múltiples bibliotecas de fármacos
US9934540B2 (en) Systems and methods for intelligent patient interface device
US20210233638A1 (en) Drug library compiler for patient devices
AU2019264737B2 (en) Distribution server for patient devices
AU2024259845A1 (en) Therapy-based database model for generating drug libraries
ES2831803T3 (es) Sistema de notificación de atención médica sensible al contexto
US20250213778A1 (en) Infusion pump control system and method for managing multiple infusion pumps in a relay sequence
ES2839092T3 (es) Sistema de infusión y bomba con recuperación de tasa de suministro de bucle cerrado configurable