BR112015014999B1 - Sistema para cuidado eletrônico do paciente - Google Patents

Sistema para cuidado eletrônico do paciente Download PDF

Info

Publication number
BR112015014999B1
BR112015014999B1 BR112015014999-5A BR112015014999A BR112015014999B1 BR 112015014999 B1 BR112015014999 B1 BR 112015014999B1 BR 112015014999 A BR112015014999 A BR 112015014999A BR 112015014999 B1 BR112015014999 B1 BR 112015014999B1
Authority
BR
Brazil
Prior art keywords
port
medical device
cqi
event
medical
Prior art date
Application number
BR112015014999-5A
Other languages
English (en)
Other versions
BR112015014999A2 (pt
Inventor
Dean Kamen
John J. Biasi
Original Assignee
Deka Products Limited Partnership
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
Priority claimed from US13/724,568 external-priority patent/US9295778B2/en
Priority claimed from US13/723,253 external-priority patent/US11210611B2/en
Priority claimed from US13/723,242 external-priority patent/US10911515B2/en
Priority claimed from US13/723,244 external-priority patent/US9151646B2/en
Priority claimed from US13/723,235 external-priority patent/US9400873B2/en
Priority claimed from PCT/US2012/071490 external-priority patent/WO2013096909A2/en
Priority claimed from US13/725,790 external-priority patent/US9677555B2/en
Priority claimed from US13/723,239 external-priority patent/US10108785B2/en
Priority claimed from US13/723,251 external-priority patent/US9636455B2/en
Priority claimed from US13/723,238 external-priority patent/US9759369B2/en
Priority claimed from US13/836,497 external-priority patent/US10242159B2/en
Application filed by Deka Products Limited Partnership filed Critical Deka Products Limited Partnership
Publication of BR112015014999A2 publication Critical patent/BR112015014999A2/pt
Publication of BR112015014999B1 publication Critical patent/BR112015014999B1/pt

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • 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/67—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 remote operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • 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
    • 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/20—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 management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Primary Health Care (AREA)
  • Epidemiology (AREA)
  • Public Health (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Chemical & Material Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Medicinal Chemistry (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Infusion, Injection, And Reservoir Apparatuses (AREA)
  • Computer And Data Communications (AREA)
  • Accommodation For Nursing Or Treatment Tables (AREA)

Abstract

sistema e aparelho para cuidados com pacientes com elementos eletrônicos. a invenção refere-se a um sistema para cuidados com pacientes com elementos eletrônicos que inclui uma rede, uma porta de instalação, uma aplicação de porta de dispositivo e um dispositivo médico. a porta de instalação é configurada para fornecer um serviço de publicação/assinatura para um aplicativo. o aplicativo de porta de dispositivo é configurado para execução pela porta de instalação. a porta de dispositivo é configurada para se comunicar através da rede fornecendo um serviço da web. o dispositivo médico está em comunicação operacional com a rede. o dispositivo médico é configurado para se comunicar com a porta de dispositivo com o uso de serviço da web.

Description

REFERÊNCIA CRUZADA A PEDIDOS RELACIONADOS
[0001] O presente pedido é um Pedido de Continuação do Pedido de Patente Não Provisório Número de Série U.S. 13/836.497, depositado em 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22).
[0002] Pedido de Patente Número de Série U.S. 13/836.497 depositado em 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e benefício do seguinte:
[0003] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30); e
[0004] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46), em que ambos são incorporados ao presente documento a título de referência em suas totalidades.
[0005] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e é também um Pedido de Continuação em Parte do seguinte:
[0006] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53), em que cada um está incorporado ao presente documento a título de referência em sua totalidade; e
[0007] Pedido Número de Série PCT PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), que está incorporado ao presente documento a título de referência em sua totalidade.
[0008] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e é também um Pedido de Continuação em Parte do Pedido de Patente Número de Série U.S. 13/723.238, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Clamping, que agora é a Publicação no U.S. US2013-0182381-A1, publicada em 18 de julho 2013 (Número do Dossiê do Advogado J47), que reivindica a prioridade e o benefício do seguinte:
[0009] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[00010] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[00011] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[00012] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30); e
[00013] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00014] Pedido de Patente Número de Série U.S. 13/723.238, que agora é a Publicação no U.S. US2013-0182381-A1, publicada em 18 de julho 2013 (Dossiê do Advogado J47) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[00015] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); e
[00016] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00017] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e é também um Pedido de Continuação em Parte do Pedido de Patente Número de Série U.S. 13/723.235, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Dispensing Oral Medications, que agora é a Publicação no U.S. US- 2013-0197693-A1, publicada em 1o de agosto 2013 (Número do Dossiê do Advogado J74), que reivindica a prioridade e benefício do seguinte:
[00018] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[00019] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[00020] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[00021] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30); e
[00022] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00023] Pedido de Patente Número de Série U.S. 13/723.235, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Dispensing Oral Medications, que agora é a Publicação no U.S. US-2013-0197693-A1, publicado em 1 de agosto 2013 (Número do Dossiê do Advogado J74) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[00024] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicado em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); e
[00025] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00026] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), é também um Pedido de Continuação em Parte do Pedido PCT Número de Série PCT/US12/71131, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Dispensing Oral Medications, que agora é a Publicação WO no WO2013/096718, publicada em 27 de junho de 2013 (Número do Dossiê do Advogado J74WO), que reivindica a prioridade e o benefício do seguinte:
[00027] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[00028] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[00029] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[00030] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46); e
[00031] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00032] Pedido PCT Número de Série PCT/US12/71131, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Dispensing Oral Medications, que agora é a Publicação WO no WO2013/096718, publicada em 27 de junho de 2013 (Número do Dossiê do Advogado J74WO) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[00033] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); e
[00034] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00035] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e é também um Pedido de Continuação em Parte do Pedido de Patente Número de Série U.S. 13/724.568, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery, que agora é a Publicação no U.S. US- 2013-0184676-A1, publicada em 18 de julho 2013 (Número do Dossiê do Advogado J75), que reivindica a prioridade e o benefício do seguinte:
[00036] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[00037] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[00038] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[00039] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30); e
[00040] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00041] Pedido de Patente Número de Série U.S. 13/724.568, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery, que agora é a Publicação no U.S. US-2013-0184676-A1, publicada em 18 de julho 2013 (Número do Dossiê do Advogado J75) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[00042] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); e
[00043] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00044] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e é também um Pedido de Continuação em Parte do Pedido de Patente Número de Série U.S. 13/725.790, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Infusing Fluid, que agora é a Publicação no U.S. US-2013-0177455, publicada em 11 de julho 2013 (Número do Dossiê do Advogado J76), que reivindica a prioridade e o benefício do seguinte:
[00045] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[00046] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[00047] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[00048] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30); e
[00049] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00050] Pedido de Patente Número de Série U.S. 13/725.790, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Infusing Fluid, que agora é a Publicação no U.S. US- 2013-0177455, publicada em 11 de julho 2013 (Número do Dossiê do Advogado J76) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[00051] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); e
[00052] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00053] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), é também um Pedido de Continuação em Parte do Pedido PCT Número de Série PCT/US12/71490, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Infusing Fluid, que agora é a Publicação WO no WO2013/096909, publicada em 27 de junho de 2013 (Número do Dossiê do Advogado J76WO), que reivindica a prioridade e o benefício do seguinte:
[00054] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[00055] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[00056] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[00057] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30); e
[00058] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00059] Pedido PCT Número de Série PCT/US12/71490, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Infusing Fluid, que agora é a Publicação WO no WO2013/096909, publicada em 27 de junho de 2013 (Número do Dossiê do Advogado J76) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[00060] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); e
[00061] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que cada um está incorporado ao presente documento a título de referência em suas totalidades.
[00062] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e é também um Pedido de Continuação em Parte do Pedido de Patente Número de Série U.S. 13/723.239, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2013- 0297330-A1, publicada em 7 de novembro de 2013 (Número do Dossiê do Advogado J77), que reivindica a prioridade e o benefício do seguinte:
[00063] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[00064] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[00065] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[00066] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46); e
[00067] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00068] Pedido de Patente Número de Série U.S. 13/723.239, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2013-0297330-A1, publicada em 7 de novembro 2013 (Número do Dossiê do Advogado J77) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[00069] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é um Pedido de Continuação em Parte do Pedido de Patente Número de Série U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011- 0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório Número de Série U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); and
[00070] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que ambos são incorporados ao presente documento a título de referência em suas totalidades.
[00071] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e é também um Pedido de Continuação em Parte do Pedido de Patente Número de Série U.S. 13/723.242, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2013- 0317753-A1, publicada em 28 de novembro de 2013 (Número do Dossiê do Advogado J78), que reivindica a prioridade e o benefício do seguinte:
[00072] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46), que está incorporado ao presente documento a título de referência em sua totalidade.
[00073] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e é também um Pedido de Continuação em Parte do Pedido de Patente Número de Série U.S. 13/723.244, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow, que agora é a Publicação no U.S. US-2013-0188040-A1, publicada em 25 de julho, 2013 (Número do Dossiê do Advogado J79), que reivindica a prioridade e o benefício do seguinte:
[00074] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[00075] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[00076] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[00077] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46); and
[00078] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00079] Pedido de Patente Número de Série U.S. 13/723.244, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow, que agora é a Publicação no U.S. US-2013-0188040-A1, publicada em 25 de julho, 2013 (Número do Dossiê do Advogado J79) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[00080] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); e
[00081] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00082] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e é também um Pedido de Continuação em Parte do Pedido PCT Número de Série PCT/US12/71142, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow, que agora é a Publicação WO no WO2013/096722, publicada em 27 de junho de 2013 (Número do Dossiê do Advogado J79WO), que reivindica a prioridade e o benefício do seguinte:
[00083] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[00084] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[00085] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[00086] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46); e
[00087] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00088] Pedido PCT Número de Série PCT/US12/71142, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow, que agora é a Publicação WO no WO2013/096722, publicada em 27 de junho de 2013 (Número do Dossiê do Advogado J79WO) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[00089] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); e
[00090] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00091] Pedido de Patente Número de Série U.S. 13/836.497 depositado em 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e é também um Pedido de Continuação em Parte do Pedido de Patente Número de Série U.S. 13/723.251, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery, que agora é a Publicação no U.S. US- 2013-0204188-A1, publicada em 8 de agosto de 2013 (Número do Dossiê do Advogado J81), que reivindica a prioridade e o benefício do seguinte:
[00092] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[00093] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[00094] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[00095] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46); e
[00096] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[00097] Pedido de Patente Número de Série U.S. 13/723.251, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery, que agora é a Publicação no U.S. US-2013-0204188-A1, publicada em 8 de agosto de 2013 (Número do Dossiê do Advogado J81) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[00098] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); e
[00099] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[000100] Pedido de Patente Número de Série U.S. 13/836.497 depositado em 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), é também um Pedido de Continuação em Parte do Pedido PCT Número de Série PCT/US12/71112, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery, que agora é a Publicação WO no WO 2013/096713, publicada em 27 de junho de 2013 (Número do Dossiê do Advogado J81WO), que reivindica a prioridade e o benefício do seguinte:
[000101] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[000102] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[000103] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[000104] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46); e
[000105] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[000106] Pedido PCT Número de Série PCT/US12/71112, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery, que agora é a Publicação WO no WO2013/096713, publicada em 27 de junho de 2013 (Número do Dossiê do Advogado J81WO) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[000107] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); and
[000108] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[000109] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), reivindica a prioridade e é também um Pedido de Continuação em Parte do Pedido de Patente Número de Série U.S. 13/723.253, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2013- 0191513-A1 (Número do Dossiê do Advogado J85), que reivindica a prioridade e o benefício do seguinte:
[000110] Pedido de Patente Provisório Número de Série U.S. 61/578.649, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Infusing Fluid (Número do Dossiê do Advogado J02);
[000111] Pedido de Patente Provisório Número de Série U.S. 61/578.658, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Estimating Liquid Delivery (Número do Dossiê do Advogado J04);
[000112] Pedido de Patente Provisório Número de Série U.S. 61/578.674, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Dispensing Oral Medications (Número do Dossiê do Advogado J05);
[000113] Pedido de Patente Provisório Número de Série U.S. 61/651.322, depositado em 24 de maio de 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado J46); e
[000114] Pedido de Patente Provisório Número de Série U.S. 61/679.117, depositado em 3 de agosto de 2012 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado J30), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[000115] Pedido de Patente Número de Série U.S. 13/723.253, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2013-0191513-A1 (Número do Dossiê do Advogado J85) reivindica a prioridade e é um Pedido de Continuação em Parte do seguinte:
[000116] Pedido de Patente Número de Série U.S. 13/333.574, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação no U.S. US-2012-0185267-A1, publicada em 19 de julho de 2012 (Número do Dossiê do Advogado I97), que é uma Continuação em Parte do Pedido de Patente no U.S. 13/011.543, depositado em 21 de janeiro de 2011 e intitulado Electronic Patient Monitoring System, que agora é a Publicação no U.S. US-2011-0313789-A1, publicada em 22 de dezembro de 2011 (Número do Dossiê do Advogado I52), que reivindica a prioridade do Pedido de Patente Provisório no U.S. 61/297.544, depositado em 22 de janeiro de 2010 e intitulado Electronic Order Intermediation System for a Medical Facility (Número do Dossiê do Advogado H53); and
[000117] Pedido PCT Número de Série PCT/US11/66588, depositado em 21 de dezembro de 2011 e intitulado System, Method, and Apparatus for Eletronic Patient Care, que agora é a Publicação WO no WO2013/095459, publicada em 12 de setembro de 2013 (Número do Dossiê do Advogado I97WO), em que cada um está incorporado ao presente documento a título de referência em sua totalidade.
[000118] Pedido de Patente Número de Série U.S. 13/836.497 depositado em, 15 de março de 2013 e intitulado System and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K22), também pode ser relacionado a um ou mais dentre os Pedidos de Patente U.S. a seguir, em todos são incorporados ao presente documento a título de referência em suas totalidades:
[000119] Pedido de Patente Número de Série U.S. 13/840.339, depositado em 15 de março de 2013 e intitulado Apparatus for Infusing Fluid (Número do Dossiê do Advogado K14);
[000120] Pedido PCT Número de Série PCT/US13/32445, depositado em 15 de março de 2013 e intitulado Apparatus for Infusing Fluid (Número do Dossiê do Advogado K14WO);
[000121] Pedido de Patente Número de Série U.S. 13/833.432, depositado em 15 de março de 2013 e intitulado Syringe Pump and Related Method, agora Pedido Publicado no U.S. US-2013-0281965- A1 (Número do Dossiê do Advogado K21);
[000122] Pedido de Patente Número de Série U.S. 13/833.712, depositado em 15 de março de 2013 e intitulado System, Method, and Apparatus for Clamping, agora U.S. Pedido Publicado no US-2013- 0272773-A1, publicado em 17 de outubro de 2013 (Número do Dossiê do Advogado K23);
[000123] Pedido de Patente Número de Série U.S. 13/834,030, depositado em 15 de março de 2013 e intitulado System, Method, and Apparatus for Monitoring, Regulating or Controlling Fluid Flow, agora U.S. Pedido Publicado no US-2013-0310990-A1, publicado em 21 de novembro de 2013 (Número do Dossiê do Advogado K28);
[000124] Pedido de Patente Provisório Número de Série U.S. 61/860.398, depositado em July 31, 2013 e intitulado System, Method, and Apparatus for Microwave Air Detection (Número do Dossiê do Advogado J31);
[000125] Pedido de Patente Provisório Número de Série U.S. 61/740.474, depositado em 21 de dezembro 2012 e intitulado System, Method, and Apparatus for Communicating Data (Número do Dossiê do Advogado J80);
[000126] Pedido de Patente Provisório Número de Série U.S. 61/900.431, depositado em 6 de novembro 2013 e intitulado System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Número do Dossiê do Advogado K52);
[000127] Pedido de Patente Provisório Número de Série U.S. 61/894.431, depositado em 23 de outubro de 2013 e intitulado Syringe Pump and Related Method (Número do Dossiê do Advogado K88);
[000128] Pedido de Patente Número de Série U.S. 13/900.655, depositado em 23 de maio 2013 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K66);
[000129] Pedido PCT Número de Série PCT/US13/42350, depositado em 23 de maio 2013 e intitulado System, Method, and Apparatus for Eletronic Patient Care (Número do Dossiê do Advogado K66WO);
[000130] Pedido de Patente Provisório Número de Série U.S. 61/843.574, depositado em 8 de julho de 2013 e intitulado System, Method, and Apparatus for Clamping (Número do Dossiê do Advogado K75);
[000131] Pedido de Patente Número de Série U.S. 13/971.258, depositado em August 20, 2013 e intitulado Electronic Patient Monitoring System (Número do Dossiê do Advogado K84); e
[000132] Pedido de Patente Provisório Número de Série U.S. 61/904.123, depositado em 14 de novembro de 2013 e intitulado Syringe Pump and Related Method (Número do Dossiê do Advogado L33).
ANTECEDENTES Campo relevante
[000133] A presente revelação refere-se a cuidados com pacientes. Mais particularmente, a presente revelação se refere a um sistema e um aparelho para cuidados com paciente eletrônicos.
Descrição de Técnica Relacionada
[000134] O fornecimento de cuidados com pacientes em um hospital necessita, em geral, da interação de inúmeros profissionais e profissionais de cuidados (por exemplo, médicos, enfermeiras, farmacêuticos, técnicos, enfermeiras especialistas, etc.) e qualquer número de dispositivos/sistemas médicos necessários para o tratamento de um dado paciente. Embora haja sistemas destinados a facilitar o processo de cuidado, tais como aqueles que incorporam registros médicos eletrônicos (“EMR”) e entrada de pedido de fornecedor computadorizado (“CPOE”), em que o processo de fornecer cuidados minuciosos a pacientes inclui pedir e entregar tratamentos médicos, tais como medicações, estão associado a várias questões não triviais.
[000135] Embora haja sistemas que incorporem registros médicos eletrônicos (“EMR”) e entrada de pedido de fornecer computadorizado (“CPOE”), o processo de pedir e entregar tratamentos médicos ainda tem o potencial de fazer com que informações cruciais não sejam comunicadas de maneira bem-sucedida, de permitir que decisões de tratamento sejam feitas sem acesso rápido a informações completas, e de atrasar a implantação de pedidos de tratamento devido a procedimentos ineficientes e desnecessariamente redundantes.
[000136] Os erros de medicação são responsáveis por aproximadamente 300 mortes e lesionam aproximadamente um milhão de pessoas a cada ano nos Estados Unidos. Os hospitais com problemas financeiros podem sofrer uma incidência aumentada de erros de medicação. As medicações associadas aos erros mais perigosos incluem insulina, narcóticos, heparina e quimioterapia. As fontes de erro incluem administrar o fármaco errado, a concentração errada do fármaco, na taxa errada, ou por meio da rota errada (as medicações podem ser administradas oralmente, de maneira intravenosa, de maneira intramuscular, de maneira subcutânea, de maneira retal, de maneira tópica à pele, por meio do olho ou da orelha, de maneira intratecal, de maneira intraperitoneal ou até mesmo de maneira intravesicular). Até mesmo com as ordens apropriadas e com a rotulagem apropriada, as medicações ainda podem ser administradas de maneira imprópria devido à escrita à mão ilegível, a comunicações mal sucedidas de pedidos, e à má pronúncia de fármacos que têm nomes semelhantes. Foi mostrado que a tendência em relação ao uso de registros médicos eletrônicos (EMR) e a sistemas de código de barras para medicações reduz a incidência de erros de medicações. Os sistemas de EMR, por exemplo, podem facilitar a entrada de pedido de fornecedor computadorizado (CPOE) e os pedidos de sinalização de fármacos que não são compatíveis as características do paciente, tais como diagnóstico, alergias, peso ou idade. No entanto, esses sistemas não foram amplamente adotados e a implantação dos mesmos pode resultar em atrasos significativos e ineficiências no pedido, na preparação e na administração de medicações.
[000137] Estima-se que os dispositivos de infusão de medicação estão envolvidos em até um terço de todos os erros de medicações que resultam em dano significativo. O fármaco errado pode ser pendurado, os parâmetros incorretos (por exemplo, a concentração de fármaco ou a taxa de infusão) podem ser inseridos, ou os parâmetros de infusão existentes podem ser mudados de maneira inapropriada. Dentre as mortes relacionadas a bombas de infusão, é possível que aproximadamente metade se deva a erros do usuário e a maioria das mesmas se deve a erros na programação do dispositivo de infusão.
[000138] Um sistema de monitoramento eficaz deve monitorar e interceder em qualquer fase do pedido de medicação e do processo de administração a fim de ajudar a minimizar qualquer um dentre vários eventos adversos que podem resultar do tratamento. O processo de tratamento com medicação pode ser separado conceitualmente em três fases: uma fase de prescrição, uma fase de preparação de medicação e uma fase de administração. Os erros podem ocorrer quando uma prescrição é escrita ou inserida, quando um fármaco é recolhido para uso ou misturado em uma solução, ou quando é administrado ao paciente. É particularmente desejável que um sistema de monitoramento não prejudique significativamente a eficiência com a qual as medicações são pedidas, preparadas ou administradas e, preferencialmente, que reduza de fato o tempo exigido para realizar essas atividades mediante a coleta, a organização e a apresentação de informações relevantes para análise.
SUMÁRIO
[000139] Em uma modalidade da presente revelação, um sistema para cuidados com pacientes com elementos eletrônicos inclui uma rede, uma porta de instalação, uma aplicação de porta de dispositivo e um dispositivo médico. A porta de instalação é configurada para fornecer um serviço de publicação-assinatura a uma aplicação. A aplicação de porta de dispositivo é configurada para a execução pela porta de instalação. A porta de dispositivo é configurada para se comunicar por meio de uma rede fornecendo-se um serviço de web. O dispositivo médico está em comunicação operativa com a rede. O dispositivo médico é configurado para se comunicar com a porta de dispositivo com o uso do serviço de web.
[000140] O sistema pode incluir adicionalmente um mecanismo de publicação-assinatura configurado para fornecer o serviço de publicação-assinatura. A rede pode ser uma rede com base em TCP/IP. A aplicação de porta de dispositivo pode ser um servidor da web do serviço de web, sendo que o dispositivo médico é um cliente do serviço de web. A aplicação de porta de dispositivo é configurada para registrar um tópico com o uso do serviço de publicação-assinatura. O sistema pode incluir uma API de integração configurada para execução pela porta de instalação. A API de integração é configurada para assinar ao tópico e comunicar um evento recebido pela assinatura ao tópico a pelo menos um servidor externo.
[000141] O tópico pode ser um ou mais dentre um tópico de eventos biomédicos relatáveis e/ou um tópico de eventos clínicos relatáveis. O tópico pode ser um tópico de evento biomédico reportável e a porta de dispositivo pode reformatar um evento de dispositivo médico recebido por meio do serviço de web em um evento biomédico reportável receptível por um assinante ao tópico por meio do mecanismo de publicação-assinatura. O dispositivo médico pode comunicar o evento de dispositivo médico por meio da rede com o uso do serviço de web. O tópico pode ser um tópico de evento clínico reportável e a porta de dispositivo pode reformatar um evento de dispositivo médico recebido por meio do serviço de web em um evento clínico reportável receptível por um assinante ao tópico por meio do mecanismo de publicação- assinatura. O dispositivo médico pode comunicar o evento de dispositivo médico por meio da rede com o uso do serviço de web
[000142] O tópico pode corresponder a pelo menos uma classe de eventos de bomba, tais como: pelo menos um dentre um evento de infusão em relação a um alarme, alerta ou notificação, um evento de infusão em relação à infusão, um evento de infusão em relação à programação, um evento de dispositivo em relação à comunicação, um evento de dispositivo em relação a uma solicitação de acesso, um evento de dispositivo em relação a atualizações de configuração, um evento de dispositivo em relação a registro em log, e/ou um evento de dispositivo em relação a consumo de energia.
[000143] O sistema pode incluir adicionalmente um ouvinte de aperfeiçoamento de qualidade contínuo configurado para execução pela porta de instalação. O ouvinte de aperfeiçoamento de qualidade contínuo pode assinar um tópico de evento biomédico reportável e um tópico de evento clínico reportável. O aperfeiçoamento de qualidade contínuo pode ser configurado para comunicar um evento biomédico reportável recebido pela assinatura ao tópico de evento biomédico reportável a um banco de dados externo. O aperfeiçoamento de qualidade contínuo pode ser configurado para comunicar um evento clínico reportável recebido pela assinatura ao tópico de evento clínico reportável a um banco de dados externo.
[000144] O banco de dados externo pode registrar pelo menos um dentre o evento biomédico reportável e o evento clínico reportável.
[000145] O sistema pode incluir um gerenciador de dispositivo executável na porta de instalação. O gerenciador de dispositivo pode ser configurado para manter uma lista de dispositivos médicos que inclui o dispositivo médico. A lista dos dispositivos médicos pode incluir uma lista de números em série correspondente à lista de dispositivos médicos.
[000146] O sistema pode incluir um cliente de monitoramento em comunicação operativa com o dispositivo médico através da rede a fim de receber informações de estado da mesma.
[000147] Em outra modalidade da presente revelação, um dispositivo médico inclui uma rede, um processador, um transceptor e um gerenciador de comunicação de porta de dispositivo. O transceptor está em comunicação operativa com o processador e é configurado para se comunicar por meio da rede. O gerenciador de comunicação de porta de dispositivo é executável no processador e é configurado para se comunicar de maneira operacional por meio do transceptor. O gerenciador de comunicação de porta de dispositivo pode ser configurado para comunicar um evento de dispositivo com o uso de um método de web na rede. O dispositivo pode ser configurado para enviar dados a um dispositivo de monitoramento por meio da rede.
[000148] A rede pode ser uma rede WiFi e o transceptor pode ser um transceptor WiFi. Em algumas modalidades, apenas o dispositivo é configurado para iniciar a comunicação com o uso do método de web.
[000149] Ainda em outra modalidade da presente revelação, um Sistema para cuidados com pacientes com elementos eletrônicos inclui uma rede, uma porta de instalação, uma aplicação de porta de dispositivo, uma aplicação de dispositivo e um dispositivo médico. A porta de instalação pode ser configurada para fornecer um serviço de publicação-assinatura. A aplicação de porta de dispositivo pode ser configurada para execução pela porta de instalação. A porta de dispositivo pode ser configurada para se comunicar por meio da rede fornecendo-se um serviço de web. A porta de dispositivo pode publicar um tópico de evento de dispositivo médico. A aplicação de dispositivo é configurada para execução na porta de instalação e é configurada para assinar o tópico de evento de dispositivo médico. A aplicação de dispositivo pode publicar um tópico de mensagem de CQI. A aplicação de dispositivo pode ser configurada para receber um evento da assinatura ao tópico de evento de dispositivo médico e publicar o evento como uma mensagem de CQI através do tópico de mensagem de CQI. O dispositivo médico está em comunicação operativa com a rede. O dispositivo médico é configurado para se comunicar com a porta de dispositivo com o uso do serviço de web e para gerar o evento como uso de um método de web do serviço de web.
[000150] A porta de dispositivo pode assinar o tópico de mensagem de CQI para receber a mensagem de CQI. O sistema pode incluir adicionalmente um ouvinte de CQI configurado para execução pela porta de instalação. O ouvinte de CQI pode ser assinado no tópico de mensagem de CQI a fim de receber a mensagem de CQI. O ouvinte de CQI pode comunicar a mensagem de CQI a um banco de dados externo. A mensagem de CQI pode ser um evento biomédico reportável e/ou um evento clínico reportável.
[000151] O sistema pode incluir um cliente de monitoramento configurar para se comunicar de maneira operacional com o dispositivo médico. O cliente de monitoramento pode e comunicar com o dispositivo médico assinando-se o tópico de mensagem de CQI.
[000152] Em outra modalidade, um sistema para cuidados com pacientes com elementos eletrônicos inclui um servidor e uma bomba (por exemplo, uma bomba de infusão ou uma bomba de seringa). O servidor tem informações relacionadas ao paciente que incluem informações de metabolismo de fármaco. A bomba é configurada para ajustar o fluxo de um fármaco em um paciente com base nas respectivas informações relacionadas ao paciente com o uso das informações de metabolismo de fármaco. A bomba recebe as informações relacionadas ao paciente a partir do servidor.
[000153] Em algumas modalidades, um sistema para cuidados com pacientes com elementos eletrônicos inclui um servidor e uma bomba. O servidor tem informações relacionadas ao paciente que incluem informações de metabolismo de fármaco. A bomba é configurada para ajustar o fluxo de um fármaco em um paciente com base nas respectivas informações relacionadas ao paciente com o uso das informações de metabolismo de fármaco. A bomba recebe as informações relacionadas ao paciente a partir do servidor.
BREVE DESCRIÇÃO DOS DESENHOS
[000154] Esses e outros aspectos se tornarão mais aparentes a partir da descrição detalhada a seguir das várias modalidades da presente revelação com referência aos desenhos, em que:
[000155] A Figura 1 mostra um diagrama de blocos de um sistema para cuidados com pacientes com elementos eletrônicos em conformidade com uma modalidade da presente revelação;
[000156] A Figura 2 mostra um diagrama de blocos de alguns aspectos do sistema da Figura 1, em conformidade com uma modalidade da presente revelação;
[000157] A Figura 3 mostra um diagrama que ilustra a agregação de diversas instalações para comunicação, em conformidade com uma modalidade da presente revelação;
[000158] A Figura 4 mostra um diagrama que ilustra um sistema para cuidados com pacientes com elementos eletrônicos, em conformidade com uma modalidade da presente revelação;
[000159] A Figura 5 mostra um método se segurança de fármaco usado para gerar um arquivo de biblioteca de administração de dose, em conformidade com uma modalidade da presente revelação;
[000160] A Figura 6 ilustra um método para infundir uma medicação, em conformidade com uma modalidade da presente revelação;
[000161] A Figura 7 ilustra um método para atualizar um dispositivo médico com software, firmware e/ou um arquivo de configuração, em conformidade com uma modalidade da presente revelação;
[000162] A Figura 8 é um diagrama de blocos para ilustrar alguns aspectos de uma comunicação entre um dispositivo médico e uma aplicação de dispositivo em conformidade com uma modalidade da presente revelação;
[000163] A Figura 9 mostra um diagrama de estado que ilustra um método para programar um dispositivo de infusão, em conformidade com uma modalidade da presente revelação;
[000164] A Figura 10 ilustra um modelo de publicação-assinatura usado pela porta de instalação da Figura 1, e pelas aplicações e pela porta de dispositivo mostrada nas Figuras 2 e 4, em conformidade com uma modalidade da presente revelação;
[000165] A Figura 11 ilustra um modelo de capacidade-registro, em conformidade com uma modalidade da presente revelação;
[000166] A Figura 12 mostra um diagrama de blocos de um sistema para ilustrar as comunicações entre um dispositivo médico e uma porta de dispositivo, em conformidade com uma modalidade da presente revelação;
[000167] A Figura 13 mostra as declarações de estrutura de dados para uso com os métodos de web para facilitar a comunicação entre o dispositivo médico e a porta de dispositivo da Figura 1, 2 ou 4 em conformidade com uma modalidade da presente revelação;
[000168] A Figura 14 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo, em conformidade com uma modalidade da presente revelação;
[000169] A Figura 15 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma verificação de estado e de comunicação, em conformidade com uma modalidade da presente revelação;
[000170] A Figura 16 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para sincronizar os respectivos relógios dos mesmos, em conformidade com uma modalidade da presente revelação;
[000171] A Figura 17 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de infusão de paciente, em conformidade com uma modalidade da presente revelação;
[000172] A Figura 18 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de instruções de paciente, em conformidade com uma modalidade da presente revelação;
[000173] A Figura 19 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de dados escalares de paciente, em conformidade com uma modalidade da presente revelação;
[000174] A Figura 20 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma sequência de transação de informações de dispositivo, em conformidade com uma modalidade da presente revelação
[000175] A Figura 21 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de notificação de alerta, em conformidade com uma modalidade da presente revelação;
[000176] A Figura 22 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de verificação de pacote de software, em conformidade com uma modalidade da presente revelação;
[000177] A Figura 23 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de verificação de arquivo de configuração de biblioteca de administração de dose, em conformidade com uma modalidade da presente revelação;
[000178] A Figura 24 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de divulgação em log de serviço, em conformidade com uma modalidade da presente revelação;
[000179] A Figura 25 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de divulgação em log de engenharia, em conformidade com uma modalidade da presente revelação; and
[000180] A Figura 26 mostra um fluxograma que ilustra um método de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de divulgação em log de infusão em conformidade com uma modalidade da presente revelação.
DESCRIÇÃO DETALHADA
[000181] A Figura 1 mostra um diagrama de blocos de um sistema 1 para cuidados com paciente eletrônicos, em conformidade com uma modalidade da presente revelação. O sistema 1 inclui aplicações/serviços de IT de instalação 11, uma instalação 10 e um serviço de nuvem 2.
[000182] A instalação 10 pode ser um hospital, uma clínica, uma instalação médica, um centro de cuidados com paciente de ambulatório, um centro de cuidados urgentes ou uma combinação ou agrupamentos dos mesmos. A instalação 10 pode incluir uma porta de instalação 21 de forma que vários dispositivos médicos 26 possam se comunicar com as aplicações/serviços de IT de instalação 11 e/ou com os serviços de nuvem 2. A instalação 10 inclui vários dispositivos médicos 26 operados e usados por enfermeiras 9 em pacientes que estão sob os cuidados da instalação 10. Os dispositivos médicos 26 podem ser bombas de infusão, bombas peristálticas, bombas de seringa, dispositivos de monitoramento de parâmetro psicológico, outros dispositivos para cuidados com paciente ou uma combinação dos mesmos.
[000183] A porta de instalação 21 pode estar hospedada, pode estar na nuvem, pode ser mantida para a instalação 10 por fornecedor de serviço, pode ser controlada, mantida ou passada por manutenção através de uma combinação de fornecedores de serviços e/ou Equipe de IT de instalação 18, e/ou pode ser implantada em um ambiente virtual ou físico. Em algumas modalidades, a porta de instalação 21 pode ser implantada em um eletrodoméstico na residência do paciente. A porta de instalação 21 pode ser usada por um hospital, um grupo de enfermagem, uma rede DE entrega integrada (“IDN”), um grupo ou uma clínica de serviços integrados, um grupo de clínicas, uma clínica central ou outra instalação ou infraestrutura de cuidados com a saúde.
[000184] Uma ferramenta de pc de biomédico 20 pode ser usada por um técnico biomédico 19 para atualizar o software dos dispositivos 26. A ferramenta de pc de biomédico 20 pode ser uma ferramenta com base em Navegador para usuários Biomédicos 19 a fim de monitorar a vida útil dos dispositivos médicos 26 dos mesmos, visualizar arquivos de log, rastrear atividades de manutenção e gerenciar a instalação de software/firmware. O técnico biomédico 19 pode ser um funcionário de hospital (ou serviço de contrato) que instala, aprimora e realiza a manutenção dos dispositivos médicos 26 (incluindo bombas de infusão) a fim de garantir que os mesmos estejam funcionando apropriadamente. A ferramenta de pc de biomédico 20 pode fazer interface com os dispositivos 26 por meio de uma conexão de dados física, tal como uma conexão USB ou uma conexão de cabo em série, de modo que o técnico biomédico 19 possa realizar esses serviços. O técnico biomédico 19 também pode usar o gerenciador de dispositivo 24 para atualizar os dispositivos 26 de maneira sem fio.
[000185] Os dispositivos 26 se comunicam com as aplicações/serviços de IT de instalação 11 (por meio de um enlace de comunicações 343) e/ou com os serviços de nuvem 2 (por meio do enlace de comunicações 344) por meio da porta de instalação 21. Os enlaces de comunicações 343 e 344 podem usar WiFi, Ethernet, TCP/IP, WiMax, cabos de fibra óptica, ou qualquer outra tecnologia da comunicação conhecida.
[000186] Os dispositivos 26 se comunicam com a porta de instalação 21 estabelecendo-se comunicações (por exemplo, por meio de registro) com a porta de dispositivo 22. A porta de instalação 21 pode ser um computador, uma máquina virtual, um dispositivo de hardware, um dispositivo de software, um dispositivo hospedado, um software em execução, semelhantes, um uma combinação dos mesmos. A porta de dispositivo 22 pode ser um software executável pela porta de instalação 21. Os dispositivos 26 podem se comunicar com a porta de dispositivo 22 com o uso de serviços da web. Em algumas modalidades específicas, apenas os dispositivos médicos 26 iniciam a comunicação com a porta de dispositivo 22 (e, desse modo, com a porta de instalação 21). A porta de dispositivo 22 pode incluir um mecanismo de encaminhamento de mensagem que suporta tanto mecanismos de publicação-assinatura quanto mecanismos de ponto a ponto. A porta de dispositivo 22 também pode fornecer capacidades de resolução de nome e registro de capacidade. O Mapeamento Orientado a Objetos pode ser usado pela porta de dispositivo 22 para a persistência de objeto em pequena escala (por exemplo, com o uso de um mecanismo de Mapeamento Orientado a Objetos (ORM)). Adicional ou alternativamente, o gerenciador de dispositivo 24 pode fornecer capacidades de resolução de nome e/ou de registro.
[000187] Em algumas modalidades da presente revelação, um dispositivo dentre os dispositivos 26 é um cliente de monitoramento, tal como um computador do tipo tablet, um dispositivo do tipo tablet, um PDA, um telefone inteligente, um computador do tipo laptop, ou um computador com base em tela sensível ao toque. Um cliente de monitoramento dos dispositivos 26 pode ter um aplicativo cliente de monitoramento dentro dos aplicativos de dispositivo 23 que permite que um profissional de cuidados se comunique com outros dispositivos dentre os dispositivos 26. O cliente de monitoramento pode ser usado para receber informações de estado a partir de um dispositivo médico dentre os dispositivos 26, receber mensagens de CQI a partir de um dispositivo médico dentre os dispositivos 26, receber RBEs ou RCEs a partir de um dispositivo médico dentre os dispositivos 26, programar um dispositivo médico dentre os dispositivos 26 ou, de outra forma, se comunicar com um dispositivo médico dentre os dispositivos 26.
[000188] Os enlaces de comunicação 343 entre os dispositivos 26 e a porta de instalação 21 podem usar WiFi, Ethernet, TCP/IP, WiMax, cabos de fibra óptica ou qualquer outra tecnologia da comunicação conhecida. Em algumas modalidades da presente revelação, os dispositivos 26 se comunicam com a porta de instalação 21 através de uma conexão celular (por exemplo, o enlace de comunicações 343 inclui uma conexão celular). Por exemplo, um ou mais dentre os dispositivos 26 podem estar localizados dentro de uma residência do paciente, dentro de uma clínica, dentro de uma instalação de campo (por exemplo, uma instalação de tenda), localização de emergência, outra localização, ou uma combinação das mesmas.
[000189] A porta de dispositivo 22 pode fornecer: (1) gerenciamento de componente de registro e de licença (por exemplo, com do gerenciador de dispositivo 24); (2) um repositório de instalação para receber, manter e rastrear novas versões de componentes instaláveis, tais como firmware/software de dispositivo, bibliotecas de administração de fármaco, software de aplicação de empresa e software de infraestrutura (por exemplo, liberação de sistema operacional, servidores de aplicação, sistema de gerenciamento de banco de dados (“DBMS”)); e/ou (3) capacidades de encaminhamento de rotinas, tais como mensagens de distribuição, tanto dentre aplicações dentro da porta de instalação 21 quanto com subsistemas externos (por exemplo, os serviços de nuvem 2).
[000190] Os ambientes de colocação em que os dispositivos médicos 26 mantêm conexões de rede ativas com a porta de dispositivo 22 são chamados ambientes conectados e podem, conforme mencionado anteriormente, ser obtidos com o uso de redes sem fio (IEEE 802.11 b/g/n). Conforme também mencionado anteriormente, em outras modalidades, a conectividade de rede pode ser obtida através de outras tecnologias, por exemplo, celular.
[000191] Os ambientes em que os dispositivos não mantêm conexões sem fio são chamados ambientes padrões, apesar do fato de que componentes de aplicação e subsistemas externos de empresa ainda possam ser conectados. Nessa modalidade específica, a porta de dispositivo 22 ainda exerce todas as três funções para componentes de aplicação e subsistemas externos de empresa, ao mesmo tempo em que a troca de mensagem que envolve os dispositivos 26 pode usar o técnico biomédico 19 (por exemplo, com o uso da ferramenta de pc de biomédico 26) para armazenar as mensagens em um dispositivo de mídia externo (por exemplo, cartões de memória).
[000192] Os assinantes de evento, tais como as aplicações de dispositivo 23, podem refinar o fluxo de evento e republicar eventos de nível maior de volta à porta de dispositivo 22. Os eventos biomédicos relatáveis (“RBE”), descritos acima, estarão dentre os eventos republicados por essas aplicações. Os RBEs podem ser relatados como mensagens de CQI aos serviços de nuvem 2. Em algumas modalidades, uma aplicação que executa na porta de instalação 21 é um Servidor Biomédico que assina os RBEs e armazena os mesmos em um banco de dados local dentro da porta de instalação 21.
[000193] Os técnicos biomédicos 19 podem usar os navegadores dos mesmos para acessar o gerenciador de dispositivo 19 e solicitar relatórios de estado de dispositivo de um dispositivo dentre os dispositivos 26. A UI do gerenciador de dispositivo 24 pode comandar o Servidor Biomédico a fim de acessar o banco de dados e gerar páginas HTML/JS para a exibição por navegador ao técnico biomédico 19.
[000194] Em algumas modalidades, antes de um novo dispositivo dentre os dispositivos médicos 26 ser autorizado para uso com a porta de dispositivo 22, o técnico biomédico 19 precisa registrar o novo dispositivo com o uso do Número de Série do mesmo. Isso pode ser validado com o uso de uma criptografia de chave assimétrica (pares de chave público/privado), e pode ser realizado como parte do processo de fabricação. Uma vez que um dispositivo dentre os dispositivos médicos é registrado com a porta de dispositivo 22, o técnico biomédico 19 configura as regulagens de protocolo sem fio e de criptografia do mesmo. Uma vez que um dispositivo médico dentre os dispositivos médicos 26 é registrado com a porta de dispositivo 22, o mesmo relata a configuração inicial do mesmo, incluindo modelo, opções e versão de hardware, firmware e de software de controle de dispositivo para armazenamento dentro da porta de dispositivo 22 e/ou dentro do gerenciador de dispositivo 24. De modo semelhante, quando um dispositivo é removido da lista de dispositivos autorizado da porta de dispositivo 22, o técnico biomédico 19 pode remover o mesmo de registro.
[000195] Cada um dos dispositivos médicos 26 pode executar um autoteste na inicialização e publicar um evento da porta de dispositivo 22 que contém os resultados. Além disso, devido ao fato de que os dispositivos médicos 26 podem executar rotineiramente por um longo intervalo de tempo entre as reinicializações, os dispositivos médicos 26 podem agendar e executar automaticamente determinados autotestes em momentos que não interferem com a segurança e/com o tratamento do paciente.
[000196] A porta de instalação 21 inclui aplicativos de dispositivo 23 que podem comunicar dados com o uso de conexões de dados de publicação-assinatura (descrito abaixo). Cada aplicativo de dispositivo dentre os aplicativos de dispositivos 23 pode ser para um tipo e/ou modelo particular de dispositivo dentre os dispositivos 26. Essas aplicações fornecem inteligência de software aos dispositivos médicos, mediante o recebimento, a filtragem e a análise de eventos brutos, e a retransmissão de interpretações de níveis superiores. Cada tipo de dispositivo médico (dentre os dispositivos médicos 26) terá uma aplicação de dispositivo correspondente (dentre as aplicações de dispositivo).
[000197] A porta de instalação 21 também inclui um gerenciador de dispositivo 24 para controlar, gerenciar ou monitorar os dispositivos 26. Por exemplo, o gerenciador de dispositivo 24 pode ser usado para atualizar e/ou transferir por download os arquivos de configuração a um dispositivo dentre os dispositivos 26. Conforme mencionado anteriormente, o técnico biomédico 19 pode controlar a atualização de software, firmware ou de arquivos de configuração dos dispositivos 26. O gerenciador de dispositivo 24 pode fornecer uma ferramenta com base em Navegador para gerenciadores e/ou técnicos de IT 18 para monitorar a vida útil do hardware, software e dos recursos de rede usados para suportar a entrega de cuidados com paciente. Ou seja, a porta de instalação 21 pode ser gerenciada por um contratado/funcionário de IT de instalação 18.
[000198] Quando uma nova versão de biblioteca de administração de dose (“DAL”) é liberada, um enlace de mensagem seguro pode enviar o arquivo de DAL a partir do gerenciador de DAL 5 para a porta de dispositivo 22 a fim de notificar o Técnico biomédico 19 sobre sua disponibilidade. Essa notificação especifica o tipo de dispositivo, a localização da DAL, a documentação, URL de notas de liberação, total de verificações e dependência de instalação. Em algumas modalidades da presente revelação, o gerenciador de dispositivo 24 tem acesso ao novo arquivo de DAL, recebe o arquivo de DAL a partir da porta de dispositivo 22, recebe o arquivo de DAL diretamente a partir do gerenciador de DAL 5 e/ou controla a atualização dos dispositivos médicos 22 com o uso do arquivo de DAL.
[000199] Em uma modalidade específica, o Técnico biomédico 19 usa o URL de notas de liberação (por exemplo, por meio de uma página da web do gerenciador de dispositivo 24 e/ou por meio da ferramenta de pc de biomédico 20) para acessar informações sobre o aprimoramento e usos do URL de instalação e do total de verificações para transferir por download e validar o arquivo de DAL e salvar o mesmo no repositório da porta de dispositivo 22. Em seguida, o técnico biomédico 19 seleciona um ou mais dentre os dispositivos médicos 22 para copiar o novo arquivo de DAL ao qual são notificados (por exemplo, por meio da porta de dispositivo 22) de que um novo arquivo de DAL está disponível para os mesmos. Na próxima reinicialização de dispositivo médico (dentre os dispositivos médicos 26 que foram selecionados para serem atualizados), o grupo selecionado dos dispositivos médicos instala a nova versão de DAL (removendo os erros) e notifica a porta de dispositivo 22 e/ou o gerenciador de dispositivo 24 sobre o resultado. Qualquer um dentre os procedimentos descritos no presente documento para atualizar o arquivo de DAL pode ser usado para atualizar firmware, software, um OS ou outros arquivos de configuração de um dispositivo médico dentre os dispositivos médicos 26.
[000200] A porta de instalação 21 pode incluir também uma API de integração 25 que permite que os dispositivos 26, os aplicativos de dispositivo 23, e/ou o gerenciador de dispositivo 24 se comuniquem com vários bancos de dados dos aplicativos de IT de instalação 11, tais como, o Sistema de Informações de Paciente 16, os Registros Médicos Eletrônicos 17, a Entrada De Pedido De Médico Computadorizada 14, o Sistema de Informações de Laboratório 15, os Serviços de Localização em Tempo Real 12, e/ou outros banco de dados ou serviços 13. A API de integração 25 possibilita que os componentes dentro da porta de instalação 21 interoperem com as aplicações/serviços de IT de instalação 11. A porta de instalação 21 pode se comunicar com os aplicativos de IT de instalação 11 por meio de um enlace de comunicações 341 que pode incluir um enlace sem fio, um enlace conectado diretamente, um enlace de TCP/IP, um enlace de internet, um enlace de comunicações de software, um enlace de comunicações de hardware, ou outra técnica ou tecnologia de comunicações.
[000201] Os registros médicos eletrônicos podem incluir dados de metabolismo de fármaco para um paciente específico. Esses dados podem ser de um teste clínico, testes genéricos ou de testes automatizados com o uso de uma resposta de dispositivos para cuidados com o paciente. Os resultados desses testes podem ser usados por uma bomba médica 26 a fim de ajustar a quantidade um fármaco particular que é dado ao paciente com base em o quão rápida ou lentamente o fármaco é metabolizado.
[000202] Os aplicativos de IT de instalação/serviços 11 suportam as funções administrativas do hospital (por exemplo admissão, descarga, transferência, codificação, faturamento, coletas, etc.). A API de integração 25 isola as diferenças nas aplicações 12 a 16 dos aplicativos de IT de instalação 11 dentre as aplicações 23 a 24, a porta de dispositivo 22 e/ou os dispositivos 26. Por exemplo, um dispositivo dentre os dispositivos 26 pode solicitar da porta de dispositivo 22 informações de programação (ou as informações de programação podem ser prosseguidas para o dispositivo dentre os dispositivos 16). A ID de paciente, a ID de bomba, o fármaco e a taxa de fluxo podem residir em um ou mais dentre os aplicativos de IT de instalação 11; a API de integração 25 fornece um formato comum para comunicar essas informações ao dispositivo 26 independente das exigências ou exigências dos aplicativos de IT de instalação 11. Essas informações podem ser reunidas pela API de integração 25 que consulta vários aplicativos dentre os aplicativos de IT de instalação 11 a fim de obter os dados e de fornecer os dados ao dispositivo 26 em um formato padronizado. A API de integração 25 pode ter capacidade para ser usada com uma variedade de aplicativos de IT de instalação 12 a 17 que têm diferentes formatos, padrões de dados, padrões de comunicação, padrões de criptografia, etc., porém fornece a uma interface padrão os aplicativos 22 a 24 e/ou os dispositivos 26.
[000203] A API de integração 25 facilita a autoprogramação de um ou mais dentre os dispositivos 26. A prescrição pode ser enviada a partir de um ou mais dentre os servidores das aplicações de IT de instalação 14. A API de integração 25 pode receber a prescrição para reformatar e enviar a mesma à porta de dispositivo 22. A porta de instalação 21 pode incluir um servidor clínico que grava um evento de prescrição em um cache persistente. O servidor clínico pode iniciar um fluxo de trabalho de autoprogramação. Esse fluxo de trabalho pode identificar um dispositivo médico dentre os dispositivos médicos 26 correspondentes ao paciente-alvo e enviar uma mensagem de comando ao dispositivo respectivo dentre os dispositivos médicos 26 de modo a carregar a prescrição. O respectivo dispositivo médico dentre os dispositivos médicos 26 irá confirmar o recebimento da prescrição e exibir uma notificação no visor. O clínico pode alocar a bolsa de medicação e pode usar um leitor de código de barras no dispositivo médico respectivo dentre os dispositivos médicos 26 a fim de validar a medicação e o paciente. O dispositivo médico respectivo dentre os dispositivos médicos 26 pode, em seguida, confirmar que a medicação é compatível com a prescrição e o clínico inicia a entrega de infusão. O dispositivo médico respectivo dentre os dispositivos médicos 26 inclui o fluxo de trabalho de autoprogramação enviando-se uma mensagem ao servidor clínico por meio da porta de dispositivo.
[000204] O cuidador usa uma UI para verificar a programação de um dispositivo médico dentre os dispositivos 26. O clínico aloca a medicação e usa a interface de usuário do dispositivo médico respectivo dentre os dispositivos médicos 26 ou para verificar os parâmetros de autoprogramação do dispositivo médico dentre os dispositivos 26 e/ou programar manualmente o dispositivo médico dentre os dispositivos médicos 26.
[000205] O PIS 16 é um sistema departamental usado pelos farmacêuticos 8 para receber, revisar, rastrear e preencher pedidos de medicações de prescrição. O sistema de EMR 17 acompanha o histórico médico do paciente na instituição de cuidados à saúde (encontros, exames, diagnósticos, procedimentos, etc.). A CPOE 14 é um sistema usado por médicos ou enfermeiras 9 para pedir testes de laboratório, fármacos de prescrição, imagens médicas e outros procedimentos clínicos. O LIS 15 é um sistema departamental usado por técnicos de laboratório para receber e processar pedidos de amostras clínicas (por exemplo tecido, sangue, urina, etc.) O RTLS 12 rastreia a localização e o estado dos dispositivos 26. O outro 13 pode ser qualquer outro banco de dados usado para cuidados com paciente.
[000206] Os serviços de nuvem 2 incluem um gerenciador de segurança de infusão hospedada em nuvem 3. A ISM 3 inclui um gerenciador de Aperfeiçoamento de Qualidade Contínuo (“CQI”) 4 e um gerenciador de DAL 5. Os supervisores de risco 6, as enfermeiras gerentes 7, e os farmacêuticos 8 podem todos receber as mensagens de CQI recuperadas pelo gerenciador de CQI 4 para facilitar o desenvolvimento de um arquivo de DAL por meio do gerenciador de DAL 5. O arquivo de DAL pode, após isso, ser transferido por download a um ou mais dentre os dispositivos 26. O gerenciador de DAL 5 pode incluir um editor Sistema de Redução de Erro de Fármaco (“DERS”) (por exemplo, o editor de DERS 112 da Figura 4, descrito abaixo), ou pode estar associado ao mesmo.
[000207] A Figura 2 mostra um diagrama de blocos de alguns aspectos do sistema da Figura 1, em conformidade com uma modalidade da presente revelação. Ou seja, a Figura 2 mostra mais detalhes de alguns aspectos da Figura 1.
[000208] A porta de dispositivo 40, o gerenciador de dispositivo 41 e a API de integração 65 são todos parte da porta de instalação 21 da Figura 1. O aplicativo de grande volume 44, o aplicativo de bomba de seringa 54 e o outro aplicativo 42 são todos aplicações que são parte dos aplicativos de dispositivo 23 da Figura 1. O gerenciador de dispositivo 41 que inclui seu banco de dados associado 45 pode ser o gerenciador de dispositivo 24 da Figura 1.
[000209] O aplicativo de Bomba de Grande Volume (“LVP”) 44 é uma aplicação para a LVP 36. O aplicativo de seringa 43 é uma aplicação para a bomba de seringa 38 e a outra aplicação 42 é uma aplicação para outro dispositivo 39. A outra aplicação 42 e o outro dispositivo 39 podem responder a qualquer dispositivo médico.
[000210] A porta de dispositivo 40 fornece conexões de dados de publicação-assinatura 58 a 64. As aplicações 42, 43, 44 também fornecem conexões de dados de publicação-assinatura 49 a 57. O padrão de mensagens de publicação-assinatura fornece a comunicação entre a porta de dispositivo 40 e/ou as aplicações 41, 42, 43, 44, 65, 72. No entanto, em modalidades adicionais, outro padrão de mensagem pode ser utilizado para comunicações.
[000211] O ouvinte de CQI 72 pode assinar várias alimentações de dados a partir das aplicações 42, 43, 44 a fim de relatar as mensagens de CQI ao gerenciador de CQI 29 que pode armazenar as mesmas no banco de dados 30. O ouvinte de CQI 72 pode relatar os resultados brutos das conexões publicadas 49 a 57 e/ou 58 a 64 e/ou pode formatar as mesmas.
[000212] Em algumas modalidades, as aplicações 42, 43, 44 reformatam os eventos brutos de um respectivo dispositivo dentre os dispositivos 36 a 39 (que são recebidos por meio de assinaturas a tópicos registrados pela porta de dispositivo 40) em mensagens de CQI. As aplicações 42, 43, 44 podem registrar os tópicos de CQI que são assinados pelo ouvinte de CQI 72. As aplicações 42, 43, 44 publicam as mensagens de CQI nesses tópicos de CQI que fazem com que o ouvinte de CQI 72 receba as mensagens de CQI. O ouvinte de CQI 72 transmite as mensagens de CQI aos serviços de nuvem 28.
[000213] Em uma modalidade específica, uma única interface GUI 33 pode ser usada para visualizar as mensagens de CQI dentro do banco de dados 30 ao mesmo tempo em que cria um arquivo de DAL 35 para uso pelos dispositivos 36, 37, 38 e 39. As atualizações de software 34 também podem ser enviadas à porta de dispositivo 40 a fim atualizar os dispositivos médicos 36, 37, 38 e 39.
[000214] A Figura 3 mostra um diagrama 73 que ilustra a agregação de diversas instalações 76 a 80 para comunicação, em conformidade com uma modalidade da presente revelação. As diversas instalações 76 a 80 podem incluir, cada uma, uma porta de instalação 21 (consulte a Figura 2) para a comunicação cm serviços de nuvem, tais como, o gerenciador de segurança de infusão 74. Em algumas modalidades, as diversas instalações 76 a 80 são parte de um grupo de instalações que compartilham um gerenciador de segurança de infusão comum 74 que não é acessível por outras instalações for a do grupo de instalações 76 a 80.
[000215] A Figura 4 mostra um diagrama que ilustra um sistema 81 para cuidados com paciente eletrônicos, em conformidade com uma modalidade da presente revelação. O sistema 81 inclui uma instalação, por exemplo, uma rede hospital 82 e serviços de nuvem 83.
[000216] A rede hospital 82 incluem uma rede informações de hospital 84, um EMR 85, uma CPOE 86, um PIS 87, um LIS 88, um mecanismo de integração 89, um componente de capacidade integração 90, um gerenciador de estado clínico 91, bancos de dados 92, 95 e 98, uma aplicação biomédica 94, um ouvinte de CQI 93, uma aplicação de bomba 96, uma aplicação de seringa 97, uma porta de dispositivo 99, uma barreira de proteção (parede proteção) 100 e dispositivos médicos 101. Em algumas modalidades, os sistemas 84 a 88 podem ser externos à rede hospital 82. Uma equipe de Técnicos biomédicos 102 pode estar disponível para usar a aplicação biomédica 94.
[000217] Os serviços de nuvem 83 incluem bancos de dados 104, 105, 106 e 113, a parede proteção 103, um receptor de CQI 108, um servidor de CQI 109, uma UI de CQI 110 e um editor de DERS 112. A farmácia e os clínicos 111 pode fazer interface com o editores de DERS 11 e/ou a UI de CQI 110. O grupo de trabalho de segurança 107 pode fazer interface com a UI de CQI 110. O editor de DERS 112 e/ou a UI de CQI 110 pode ser uma interface com base em navegador.
[000218] O HIS 84 suporta as funções administrativas do hospital (por exemplo admissão, descarga, transferência, codificação, faturamento, coletas). Os EMR 85 acompanham o histórico médico de paciente na instituição de cuidados com o paciente (encontros, exames, diagnósticos, procedimentos, etc.). A CPOE 86 é um sistema usado por médicos para pedir testes de laboratório, fármacos de prescrição, imagens médicas e outros procedimentos clínicos. O PIS 97 é um sistema departamental usado por farmacêuticos para receber, revisar, rastrear e preencher pedidos de medicações de prescrição. O LIS 88 é um sistema departamental usado por técnicos de laboratório para receber e processor pedidos de amostras clínicas (por exemplo tecido, sangue, urina, etc.). O mecanismo de integração de hospital 89 fornece capacidades de tradução de mensagens para possibilitar que os sistemas de informações 84 a 88 interopere entre si e com sistemas externos. A maiores desses mecanismos mapeiam entre diferentes dialetos de HL7. Um Motor de Integração pode estar localizado na porta de dispositivo 99 para interoperar com o HIS, EMR e PIS, através do mecanismo de integração de hospital 89. A porta de dispositivo 99 fornece um mecanismo de encaminhamento de mensagem, que suportar tanto o mecanismos de publicação-assinatura quando o mecanismo de ponto a ponto. A porta de dispositivo 99 também fornece capacidades de resolução de nome e registro de capacidade.
[000219] Vários dispositivos 101 são usados para tratar pacientes, tais como, dispositivos de infusão que entregam medicação, nutrição e hidratação em forma líquida a pacientes por meio de rotas intravenosas (IV) ou subcutâneas. Uma aplicação de bomba 96 e uma aplicação de seringa 97 são aplicações que fornecem uma inteligência software a dispositivos médicos 101, mediante o recebimento, a filtragem e a análise de eventos brutos e a retransmissão de interpretações de nível superior. Cada tipo de dispositivo médico dentre os dispositivos 101 pode ter uma aplicação de dispositivo correspondente, por exemplo, uma dentre as aplicações 96 a 97.
[000220] Cada dispositivo de infusão dos dispositivos 101 pode ser usado para controlar a entrega de um infusato específico (hidratação, nutrição, sangue ou medicação em forma líquida) a um paciente específico. Os ajustes de dose, na forma de doses de carregamento ou de bolo alimentar, ou titulação de dose podem ser considerados como fases de infusão separadas dentro de uma infusão ao paciente. Uma coleta de infusões para o mesmo paciente como parte da mesma terapia é considerada como um “Histórico de Infusão” que pode ser registrado por um servidor de CQI 109.
[000221] Uma infusão pode ser organizada em uma fase de organização, uma fase de programação, e uma fase de entrega. Durante a fase de organização, um clínico verifica o infusato, o paciente e a bomba e conecta a tubagem a partir do infusato à bomba e a bimba ao paciente, o que pode ser registrado pelo servidor de CQI 109. Durante a fase de programação, o clínico insere os parâmetros de dose na bomba e a bomba verifica os mesmo com o uso da versão de DAL instalada (que também pode ser registrada pelo servidor de CQI 109). Durante a fase de entrega, a bomba entrega o volume especificado de infusato na taxa programada.
[000222] Cada um dos dispositivos médicos 101 pode detectar condições de alarme (isto é, situações em que a bomba não está em infusão), assim como, condições de alerta e informativas, que podem ou não ser crucial em relação à segurança. Cada um dentre os dispositivos médicos 101 podem tentar estabelecer uma conexão de rede segura à porta de dispositivo 99. Cada um dos dispositivos médicos 101 pode coletar programação, estado de entrega e eventos de exceção para cada infusão e fornecem os mesmos à porta de dispositivo 99 de modo que possam ser relatados como mensagens de CQI ao receptor de CQI 108. Cada um dentre os dispositivos médicos 101 podem comunicar esses eventos à porta de dispositivo 99, que roteia os dados ao receptor de CQI 108 (direta ou indiretamente). Em algumas modalidades, caso, ou quando, um dispositivo médico dentre os dispositivos médicos 101 não possa, ou não puder, estabelecer ou manter uma conexão de trabalho à porta de dispositivo 99, o dispositivo médico pode salvar esses eventos em um armazenador temporário interno e permitir que o técnico biomédico 102 copie os mesmos em uma mídia portátil (por exemplo, um cartão de memória) com ou sem o uso da aplicação biomédica 94. Em algumas modalidades, esses eventos podem ser transferidos por download por meio do aplicativo biomédico 94 que executa em um computador pessoal que tem um cabo USB acoplado ao dispositivo médico.
[000223] O aplicativo biomédico 94 fornece uma com base em navegador para usuários biomédicos 102 a fim de monitorar a vida útil dos dispositivos médicos respectivos 101, visualizar os arquivos de log, rastrear atividades de manutenção e gerenciar a instalação de software/firmware. Os arquivos de log, os logs e manutenção e os dados de rastreamento de instalação e de aprimoramento de software/firmware podem ser armazenados no banco de dados 95.
[000224] A porta de dispositivo 99 pode ser um dispositivo no leito que se acopla a todos os dispositivos 101 associados a um paciente particular. Em outra modalidade, a porta de dispositivo 99 é uma aplicação de software executável em uma porta de instalação. Ainda em outra modalidade, a porta de dispositivo 99 é um software executável em um eletrodoméstico no leito (por exemplo, um computador compacto). A porta de dispositivo 99 pode ser um roteador de mensagem, um registro de serviço e/ou um registro de autorização de bomba. As aplicações de dispositivo 96 a 97 podem registrar tipos de mensagem e publicar mensagens ao dispositivo de porta 99. Qualquer dispositivo médico dentre os dispositivos médicos 101, incluindo sensores que podem ser plugados em um dispositivo médico (consulte outro 37 na Figura 2) dentre os dispositivos médicos 101 (por exemplo, monitor respiratório na PCA) pode ser usado para publicar dados por meio do dispositivo de porta 99. As aplicações de dispositivo 96 a 97 podem atuar “refinarias de informações”. Cada uma dentre as aplicações de dispositivo 96 a 97 assina mensagens de um tipo de dispositivo no leito dentre os dispositivos médicos 101 por meio do dispositivo de porta 99. Cada uma das aplicações de dispositivo 96 a 97 podem sintetizar informações de CQI, clínicas e biomédicas a partir de um fluxo de eventos recebidos a partir de um ou mais dentre os dispositivos médicos 101 através da porta de dispositivo 99. Em algumas modalidades, cada uma das aplicações de dispositivo 96 a 97 republica esses eventos de nível superior à porta de dispositivo 99 ou a outros assinantes, tais como, o ouvinte de CQI 93.
[000225] Em algumas modalidades, algumas das mensagens de CQI podem ser usadas para funções de autodocumentação, autoprogramação e de faturamento. Ainda em algumas modalidades adicionais, as mensagens de CQI podem ser usadas para a autodocumentação a partir do dispositivo médico 101 nos EMR 85 e/ou para a autoprogramação do dispositivo médico 101 a partir de sistema de eMAR (por exemplo, parte do HIS 84). As mensagens de CQI podem incluir eventos de segurança de fármaco e informações de latência.
[000226] O ouvinte de CQI 93 assinar os eventos relacionados ao aperfeiçoamento de qualidade contínuo de segurança de fármaco e garante a entrega confiável ao ambiente hospedado. O ouvinte de CQI 93 pode armazenar os eventos no banco de dados 98 para transmissão periódica ao receptor de CQI 108 (através da parede proteção 103).
[000227] O receptor de CQI 108, o servidor de CQI 109 e a UI de CQI 101 pode ser fornecido em um ambiente hospedado 83 (isto é, serviços de nuvem). Uma replicação de banco de dados mestre-escravo (o banco de dados 105 como mestre e o 106 como escravo) pode ser usada no ambiente hospedado 83 a fim de reduzir os conflitos entre as consultas de usuário e atualizações de dados de CQI. O servidor de CQI 109 pode pós-processar eventos de CQI em uma forma de sumário (reportável) antes armazenar os mesmos no banco de dados 105 a fim de reduzir o tempo de resposta para consultas de nível superior e para solicitações de apresentação. A UI de CQI 110 pode fornecer uma série de relatórios padrões (conformidade, violações de limite, segurança de titulação, eventos por estágio e eventos por prioridade). O servidor de CQI 109 pode suportar uma API de consulta a ser usada pelo editor de DERS 445 e pela UI de CQI 110 para fazer uma busca detalhada em sumários mais detalhados e de detalhes de mensagens de CQI particulares.
[000228] O servidor de CQI 109 fornece serviços de análise e de consulta para um usuário com o uso da UI de CQI 110. O servidor de CQI 109 pode fornecer ao usuário da UI de CQI 110 totais de sumário para mensagens de CQI e atualizar tabelas de sumário (em um intervalo configurável). O propósito dessas tabelas de sumário é reduzir o tempo de resposta para consultas de CQI de nível superior. Esses sumários podem cobrir as seguintes medidas estatísticas: (1) programar modos usados, tais como infusões com o uso de limites vs. coringa de DERS; (2) violações de limite maleável e rigoroso; (3) informações de segurança de titulação, tal como, regulagens de aumento/diminuição de titulação e violações de limite de dose; (4) eventos clínicos relatáveis (por exemplo, RCEs 149 da Figura 8, descritos abaixo) por nível de prioridade; e/ou (5) eventos clínicos relatáveis (por exemplo, RCE 149 da Figura 8, descrito abaixo) por estágio de infusão. Cada um dentre esses sumários pode computar subtotais para as seguintes visualizações de dados: (1) nome de organização; (2) nome de instituição (por exemplo, nome de instalação); (3) área de cuidados; (4) hora do dia; e/ou (5) semana.
[000229] Uma API de consulta de serviço de web pode ser usada para possibilitar que a UI de CQI 110 e/ou o editor de DERS 112 selecione: (1) totais de sumário para cada visualização de dados descrita acima, filtrados pelos seletores especificados; (2) detalhe de RCE por infusão; e/ou (3) real programação, estatísticas de limites e de infusão por paciente (isto é, históricos de infusão). Em algumas modalidades específicas, o editor de DERS 112 e/ou de qualquer sistema dos serviços hospedados 83 pode se basear em um servidor de aplicação, em conformidade com J2EE. Os bancos de dados 104, 105, 106 e 113 podem usar um servidor de gerenciamento de banco de dados.
[000230] Uma vez que o J2EE e o servidor de gerenciamento de bancos de dados são instalados e configurados, as tabelas de banco de dados compartilhadas a seguir podem ser importadas para realizar uma inicialização de banco de dados de DERS 113: (1) tabelas de referência, tais como, unidades de medida, modos de dose, etc.; (2) tabelas de controle de acesso para usuários administrativos, funções, privilégios e permissões; (3) lista de medicação de DERS; (4) lista de grupos de cuidados de NDNQI; (5) atributos de instituição; e/ou (6) tabelas de banco de dados exigidas pelo editor de DERS 112. O editor de DERS 112 pode ser usado para adicionar ou editar as organizações, para adicionar ou para editar as regiões e/ou para adicionar ou editar o controle de acesso (cada um com ou sem atributos).
[000231] Em uma modalidade, o Editor de DERS 112 e/ou o banco de dados de DERS pode ser executado em um único servidor de aplicação e ambiente de banco de dados para múltiplas instalações 82. Ainda em outra modalidade, cada instituição 82 pode se hospedar ou pode estar hospedada em seu próprio ambiente virtual (por exemplo, serviços de nuvem 2).
[000232] Uma UI de CQI 110 e/ou editor de DERS 112 pode suportar uma interface de HTTP/Javascript para produzir relatório de CQI e operações de busca detalhada interativas para usuário que executam um navegador da web, em algumas modalidades específicas.
[000233] As mensagens de CQI são recebidas pelo receptor de CQI 108 que armazena as mesmas no banco de dados 105. Caso o receptor de CQI 108 não possa processar todas as mensagens de CQI de entrada em uma taxa predeterminada e/ou o armazenador temporário do CQI do receptor 108 esteja completo, as mensagens de CQI são armazenadas temporariamente no banco de dados 104, que pode ser acessado pelo receptor de CQI 108 para o armazenamento dentro do banco de dados 105 quando o receptor de CQI é descarregado. O banco de dados 105 pode ser replicado pelo banco de dados 106. O banco de dados 106 é acessível por usuário através do servidor de CQI 109 com o uso ou da interface de usuário de CQI 110 e/ou do editor de DERS 112.
[000234] Os registros dos bancos de dados de CQI 105, 106 dependem do editor de DERS 112. Os registros incluem: (1) tabelas de referência, tais como, unidades de medida, modos de dose, etc.; (2) tabelas de controle de acesso para usuários administrativos, funções, privilégios e permissões; (3) lista de medicação de DERS; (4) lista de grupo de cuidados de NDNQI; e/ou (5) atributos de instituição.
[000235] Visto que essas referências dependem da versão do editor de banco de dados de DERS 113, a consistência é preferencial. Uma opção é compartilhar as tabelas entre os bancos de dados 113, 105, 106. Embora essa opção seja conveniente, a mesma aumenta o acoplamento de colocação entre os dois de dados 113 e 105, 106. Alternativamente, o acoplamento pode ser reduzido mantendo-se cópias de apenas leitura dessas tabelas no interior dos bancos de dados de CQI 105, 106, com um procedimento a fim de atualiza os mesmo sempre que os mesmos forem mudados no Editor de DERS 112.
[000236] O controle de acesso para os bancos de dados de CQI 105, 106 podem ser semelhantes em estrutura, porém diferentes em conteúdo versus o banco de dados de DERS 113. Alguns usuários podem ser definidos para o servidor de CQI 109, porém não para o editor de DERS 112. Até mesmo para os usuários que aparecem em ambas as permissões podem diferir (por exemplo, alguns dados de CQI são de apenas leitura).
[000237] Determinadas tabelas de banco de dados (por exemplo, eventos clínicos relatáveis e sumários estatísticos) podem ser exigidos pelos bancos de dados de CQI 105, 106 e são organizados quando os bancos de dados de CQI 105, 106 são criados.
[000238] A UI de CQI 110 e/ou o editor de DERS 112 pode, cada um, utilizar os dados a partir do servidor de CQI 109 (e, desse modo, os dados do banco de dados 106) e os dados do editor de DERS 112 (e, assim, com o banco de dados 113) a fim de gerar um arquivo de DAL 114.
[000239] O gerenciador de estado clínico 91 é um intermediário entre a porta de dispositivo 99, o mecanismo de integração 89 que orquestra fluxos de trabalho assíncronos quer envolvem diferentes atuadores e componentes.
[000240] Os farmacêuticos e os clínicos de seleção 111 usam o editor de DERS 112 para definir limites de dose para uma instituição e para criar um arquivo de DAL 114 (que pode estar em formato XML). Os limites de dose podem ser difundidos com o uso de um processo bem definido, controlado cuidadosamente, completamente documentado, com procedimentos de liberação controlados. Os limites de dose podem ser especificados com o uso do editor de DERS 112 do gerenciador de DAL 5. A instalação 82 pode usar modelos de referência comuns para medicações, áreas de cuidados, modos de dose, etc. a fim de facilitar uma comparação institucional cruzada posterior. O editor de DERS 112 pode ser executado em um ambiente hospedado 83, de modo que os usuários acessem o mesmo com o uso de um navegador da web. Em algumas modalidades, nenhum software do lado do cliente é exigido para executar o editor de DERS 112 exceto um navegador suficiente. O editor de DERS 112 pode fornecer limites e padrões de dose que organizados por área de cuidado, medicação, uso clínico e concentração de fármaco. O editor de DERS 112 pode suportar uma interface de consulta ao servidor de CQI 109 a fim de integrar a pesquisa e a análise de discernimentos de CQI para aperfeiçoar a próxima versão de DAL.
[000241] A Figura 5 mostra um método de segurança de fármaco 115 usado para gerar um arquivo de DAL, em conformidade com uma modalidade da presente revelação. O método 115 pode ser usado com o sistema 1 da Figura 1, o Sistema 27 da Figura 2, o sistema 81 da Figura 4, ou qualquer outro sistema de cuidados com paciente eletrônicos.
[000242] Os participantes de uma farmácia e de uma área de cuidados clínicos (por exemplo, usuários selecionados a partir de 6, 7, 8, 9, 18 e 18 da Figura 1 ou 102, 107 e 111 da Figura 4) podem ser selecionados para auxiliar na geração e na definição de um arquivo de DAL 35 (consulte a Figura 2) que contém regras de segurança para infusões de fármaco que podem considerar o tipo de medicação, área de cuidados clínicos, modo de dose (por exemplo, estratégia de dose com base em quantidade, com base em taxa ou com base em peso (carga, bolo alimentar, rampa), etc.
[000243] O método 115 inclui os atos 116 e 117. O ato 116 inclui os atos 118 a 125 como subatos e o ato 117 inclui os atos 126 a 127 como subatos. O ato 116 gera um arquivo de DAL e o ato 117 monitora o uso do arquivo de DAL par atualizar o arquivo de DAL 35 (consulte a Figura 2).
[000244] O ato 122 organiza um arquivo de DAL, por exemplo, um arquivo de DAL inicial sem entradas de campo ou um arquivo de DAL modelo. O ato 123 recebe modificações no arquivo de DAL, em conformidade com uma entrada de um dentre os usuários selecionados (por exemplo, por meio da interface GUI 112 da Figura 4). O ato 121 revisa o arquivo de DAL, por exemplo, executando-se um simulador de dispositivo médico por meio da interface GUI 112 da Figura 4. Após a revisão durante o ato 121, um arquivo de DAL piloto é liberado (eletronicamente) no ato 120. O ato 118 aprova o arquivo de DAL piloto. No entanto, após o piloto ter concluído, ajustes podem ser feitos à DAL. O ato 118 pode ser realizado por meio do clique em um botão “aprovação” em um navegador da web a fim de aprovar o uso de um arquivo referenciado (por exemplo, referenciado pelo número de versão, data de criação, etc.).
[000245] No ato 119, o arquivo de DAL é liberado e é enviado ao dispositivo médico no ato 127. No ato 125, o servidor de CQI importa os dados de referência (isto é, medicações, áreas de cuidados, modos de dose, etc.) a partir do arquivo de DAL. Mediante a liberação de DAL, um arquivo que contém os registros de dose é liberado tanto para o hospital quanto para o ambiente de CQI. Um técnico biomédico instala a DAL em cada dispositivo de infusão após a liberação no ato 119. O ato 126 é o dispositivo médico que envia os eventos de CQI ao receptor de CQI 108.
[000246] Durante as infusões, os dispositivos médicos geram eventos de CQI (isto é, mensagens de CQI). As mensagens de CQI podem incluir informações sobre quando uma infusão normal ocorre, quando uma infusão ignora as verificações de DERS, quando um limite maleável é excedido e substituído, e/ou quando um limite maleável rigoroso é excedido e a dose é reprogramada, dentre outros.
[000247] Os eventos de CQI são transmitidos a um Servidor de CQI no ato 126, que coleta e armazena os mesmos. Os supervisores de risco podem executar os relatórios que resume esses eventos e fornecem capacidades de busca detalhada para identificar oportunidades para o aperfeiçoamento de procedimento no ato 124. De modo semelhante, os farmacêuticos e os clínicos podem consultar o banco de dados de CQI a fim de identificar as oportunidades para aperfeiçoar esses registros na próxima liberação da DAL no ato 124. Ou seja, no ato 124, as mensagens de CQI são analisadas ou revisadas. As modificações ao arquivo de DAL podem ser feitas no ato 123 para criar uma nova versão do arquivo de DAL.
[000248] A Figura 6 ilustra um método 128 de infusão de um medicamento de acordo com uma modalidade da presente revelação. O método 128 inclui os atos 129, 131, 133, 134 e 135. O método 128 pode ser usado com o sistema 1 da Figura 1, o sistema 27 da Figura 2, o sistema 81 da Figura 4 ou qualquer outro sistema para cuidados com paciente com elementos eletrônicos.
[000249] No ato 129, um médico escreve uma prescrição eletronicamente. O pedido é inserido no CPOE 130, que é enviado eletronicamente para uma farmácia. No ato 131, o farmacêutico revisa o pedido, fazendo avaliações quanto a interações de fármacos e suprimento de medicação, e preenche a prescrição ou modifica a prescrição (por exemplo, ao consultar o médico). Também no ato 131, a prescrição é aperfeiçoada e uma solicitação é submetida a um PIS 132. No ato 133, a prescrição é dispensada. Isso pode ser feito se (incluindo, porém sem limitação a): for utilizado um composto pré- preparado com a medicação já na concentração desejada; a dose e a concentração desejadas forem compostas, pelo farmacêutico, na farmácia; a dose e a concentração desejadas forem compostas por um profissional clínico (por exemplo, uma enfermeira) no leito do paciente.
[000250] A seguir, a dose é administrada para o paciente no ato 134. Em um cenário de internação (hospital ou enfermaria residencial), tipicamente, um profissional clínico realiza a administração de dose. Em um cenário de ambulatório ou residencial, a administração pode ser realizada por um profissional clínico, um membro da família do paciente ou pelos próprios pacientes. Os procedimentos de segurança de fármaco buscam garantir que os testes de “paciente certo”, de “medicação certa”, de “dose certa”, de “tempo certo” e de “rota certa” sejam cumpridos. Isso pode ser alcançado de diversas formas, incluindo um sistema de ponto de cuidado com leito, através de uma codificação de barra do paciente e da medicação, e/ou através do uso da programação automática. A documentação do registro é submetida a um sistema de manutenção de registro no ato 135. No ato 135, a documentação é fornecida a um sistema de EMR para atualizar o quadro do paciente.
[000251] A Figura 7 ilustra um método 137 para atualizar um dispositivo médico com software, firmware e/ou um arquivo de configuração de acordo com uma modalidade da presente revelação. O método 137 inclui os atos 138 a 143. O método 137 pode ser usado com o sistema 1 da Figura 1, com o sistema 27 da Figura 2, com o sistema 81 da Figura 4 ou qualquer outro sistema para cuidados com paciente com elementos eletrônicos.
[000252] No ato 138, um técnico biomédico 19 (vide Figura 1) instala o software, o firmware ou os arquivos de configuração em um dispositivo médico (por exemplo, pela primeira vez) e/ou, no ato 140, o técnico biomédico atualiza o software, o firmware ou os arquivos de configuração em um dispositivo médico. No ato 139, o dispositivo médico é configurado ou reconfigurado. Os atos 138, 139 e/140 podem ser realizados sem fio ou através de uma conexão física entre uma ferramenta biomédica 20 (vide Figura 1) e o dispositivo médico.
[000253] Um técnico biomédico 19 pode realizar o ato 138 e/ou o ato 140. No ato 141, o dispositivo médico é monitorado (por exemplo, através de mensagens de CQI, etc.) Em algumas modalidades, um técnico biomédico 19 pode copiar os arquivos de evento de CQI a partir de dispositivos de infusão para cartões de memória portáteis para transferência por upload subsequente para um servidor de CQI. O ato 141 pode ser usado para: identificar quando os dispositivos necessitam de agendamento para manutenção preventiva; identificar se o dispositivo médico necessita de transferência por download de software, de firmware, de arquivos de configuração ou de outras atualizações e melhorias; transferir por upload arquivos de log de dispositivo; e/ou realizar outras tarefas de diagnóstico e manutenção.
[000254] O ato 141 monitora o dispositivo médico (por exemplo, sem fio). O ato 142 determina se quaisquer problemas são identificados no dispositivo médico. Os problemas são, por exemplo, o dispositivo médico não estar operando dentro dos parâmetros pré-determinados, o dispositivo médico estar detectando um erro interno e/ou o dispositivo médico determinar que seu software, firmware ou arquivos de configuração estão desatualizados. No ato 143, o dispositivo médico é consertado em resposta ao problema identificado no dispositivo médico.
[000255] A Figura 8 mostra um diagrama de blocos 144 para ilustrar alguns aspectos de uma comunicação entre um dispositivo médico 145 (por exemplo, uma bomba de infusão) e uma aplicação de dispositivo 151 (por exemplo, uma aplicação de bomba) de acordo com uma modalidade da presente revelação. Embora uma bomba 145 seja descrita no presente documento com referência à Figura 8, contempla- se o uso de qualquer outro dispositivo médico no lugar de, ou com, a bomba 145 para gerar o evento 146.
[000256] Mostra-se, no diagrama de blocos 114, um dispositivo médico 145 (por exemplo, uma bomba de infusão) que comunica um evento 146 (por exemplo, um evento de bomba) a uma porta de dispositivo 147. O evento de bomba 146 pode ser uma mensagem de CQI, pode ser a base para uma mensagem de CQI, ou pode ser outros dados, tais como dados brutos, a partir do dispositivo médico 145. O evento de bomba 146 pode ser um parâmetro de operação, um parâmetro de entrega e/ou outros eventos de operação. Em algumas modalidades específicas, o evento de bomba 146 pode usar o Protocolo de Acesso de Objeto Simples (“SOAP”) que usa Serviços de web (“WS”) endereçados. Em algumas modalidades, o evento 146 é comunicado com o uso de Transferência de Estado Representacional (“REST”) que pode usar o protocolo HTTP (ou HTTPS) inteiro.
[000257] O evento 146 pode ser um evento conforme mostrado na Tabela 1 a seguir:
Figure img0001
Figure img0002
Figure img0003
Figure img0004
Tabela 1
[000258] Os itens listados como 1, 2, 3, 4, 5, 6, 7, 8 e 9 na Tabela 1 são classes de evento de bomba. Quando o dispositivo médico 145 não está conectado à porta de dispositivo 147, esses eventos são armazenados em um armazenamento temporário de memória local do dispositivo médico 145. Enquanto conectados (e uma vez reconectados), esses eventos são publicados à porta de dispositivo 147 usando-se um protocolo seguro, por exemplo, SSL, SSH, criptografia de chave simétrica, e/ou criptografia de chave assimétrica. Conforme mencionado anteriormente, a porta de dispositivo 147 pode agir como (ou conter) um mecanismo de publicação-assinatura que é configurado para rotear eventos de bomba para assinantes.
[000259] Referindo-se novamente à Figura 1, os eventos de bomba podem ser enviados para o gerenciador de CQI 4 que relata os Eventos de Dispositivo dos dispositivos 26. Esses eventos podem ser usados para monitorar uma frota inteira de dispositivos médicos 26 em várias instalações 10. Por exemplo, a Matriz de Estado de Hardware de Dispositivo 9.71 pode ser convertida em uma mensagem de CQI e ser comunicada ao gerenciador de CQI 4. Um usuário pode acessar o gerenciador de CQI 4 para agendar eventos de manutenção, pedir novas peças tendo como base esses dados, fornecer manutenção preditiva ou preventiva e/ou pedir novas peças por razões preventivas ou razões preditivas. O usuário pode usar heurísticas determinísticas para determinar o que pedir, quando pedir e/ou quando sinalizar alguns dos dispositivos 26 em diversas instalações 10 para manutenção. O gerenciador de CQI 4 pode ser usado para o gerenciamento de cadeia de fornecedores de peças para uma frota de dispositivos 26 e pode fornecer informações em tempo real sobre o estado da frota de dispositivos 26. Por exemplo, a Matriz de Estado de Hardware de Dispositivo pode incluir informações de bateria tais como a corrente em carga total, o que indica a saúde da bateria interna. Para a totalidade ou um subconjunto dos dispositivos 26 dentre as diversas instalações 10, o gerenciador de CQI 4 pode automaticamente pedir novas baterias quando a saúde da bateria cair abaixo de um limiar pré-determinado. Adicionalmente ou alternativamente, o gerenciador de CQI 4 pode automaticamente agendar a bateria para substituição nesses dispositivos identificados dos dispositivos 26.
[000260] Referindo-se agora à Figura 8, uma aplicação de dispositivo 151 (por exemplo, uma aplicação de bomba configurada para operação com uma bomba) pode ser executada na porta de dispositivo 147 (em algumas modalidades, esses podem ser hardware e/ou software diferentes). A aplicação de dispositivo 151 assina a eventos publicados através do dispositivo médico 145.
[000261] A aplicação de bomba 151 pode processar o fluxo de eventos brutos e refinar esses em fluxos de eventos clínicos de nível mais alto, por exemplo, o evento clínico reportável 149 que pode ser relatado a um servidor dos serviços de nuvem hospedados para armazenamento no mesmo (por exemplo, o banco de dados 30 da Figura 2).
[000262] Em algumas modalidades da presente revelação, a aplicação de dispositivo 151 é implantada em um servidor de aplicação de J2EE como um feixe acionado por mensagem (“MDB”). O MDB é um componente sem estado que assina a um tópico de Serviço de Mensagem de Java (JMS), por exemplo, PumpTopic 150. Um servidor de aplicação da porta de dispositivo 147 pode ativar a aplicação de dispositivo 151 em uma discussão de trabalho quando uma mensagem está disponível.
[000263] A aplicação de dispositivo 151 é um componente com estado e contém uma instância de manipulador de bomba 153 para cada uma das bombas 145 implantadas na instituição. O despachante de bomba 152 mantém uma tabela de pesquisa dos manipuladores de bomba 153 que usam os números em série da bomba 145 como uma chave única.
[000264] O MDB de bomba usa o serviço de nomeação do servidor de aplicação para acessar a aplicação de bomba 151. O mesmo obtém o número em série da bomba 145 a partir do cabeçalho de mensagem e usa o despachante de bomba 152 para encontrar o manipulador de bomba adequado dentre os manipuladores de bombas 153. Se o manipulador de bomba respectivo dentre os manipuladores de bomba 153 estiver ocupado (processando outra mensagem, outra discussão, etc.), o MDB de bomba enfileira a mensagem para o despachante de bomba 152 (para garantir que as mensagens sejam processadas em sequência). Se o manipulador de bomba respectivo dentre os manipuladores de bomba 153 estiver ocioso, o MDB de bomba pede ao manipulador de bomba respectivo dos manipuladores de bomba 153 que processe o evento. Cada um dos manipuladores de bomba dentre os manipuladores de bomba 153 mantém uma definição de máquinas de estado finito (“FSM”), em que cada uma processa um subconjunto relevante dos eventos de bomba (vide a Tabela 1 acima), que incluem uma FSM de bomba 156, uma FSM de programa 157 e uma FSM de entrega 158.
[000265] A FSM de bomba 156 é uma máquina de estado de nível de topo que processa os eventos que não pertencem a nenhuma infusão. A FSM de programa 157 é uma máquina de estado filho que é ativada quando um contexto de programação de infusão é iniciado e é responsável por processar os eventos de programação de infusão. A FSM de entrega 158 é uma máquina de estado filho que é ativada quando uma entrega de infusão é iniciada e é responsável por processar os eventos operacionais durante uma infusão. Uma FSM de programação separada 157 e a FSM de entrega 158 podem ser usadas devido ao fato de que uma infusão secundária (que inclui carregamento, bolo ou titulação) pode ser programada enquanto uma infusão primária está em progresso. O modelo de operação do dispositivo médico 145, por exemplo, a FSM de bomba 156, pode ser usada para construir eventos clínicos reportáveis (RCEs) ou para construir eventos biomédicos reportáveis (RBEs). Por exemplo, a FSM de bomba 156 pode: rastrear a respeito do fato de a bomba 145 completar uma infusão e reverter para outra que estava suspensa; rastrear qual foi suspensa; rastrear a programação de uma infusão enquanto outra está em execução; e/ou rastrear mais que um alarme operacional de prioridade alta que pode ocorrer em algum momento. Isto é, a FSM de bomba 156 pode incluir modelos de estado aninhado.
[000266] Cada um dos manipuladores de bomba dentre os manipuladores de bomba 153 também pode manter alguns objetos de contexto para reter a informações de contexto de programação e de entrega. Esses objetos de contexto serão gerados como Eventos Biomédicos (para rastrear a utilização de bomba) quando completos e persistirão para a recuperação, caso a aplicação de bomba 151 necessite ser reiniciada. Os objetos de contexto podem incluir um estado de infusão, um modo de infusão e um segmento de infusão. O estado de infusão inclui os dados de estado de programação/entrega para infusões principais e secundárias. O modo de infusão inclui dados de estado de programação/entrega para uma dose/taxa particular (por exemplo, carregamento, bolo e/ou titulação). O segmento de infusão inclui o estado de entrega para um período operacional dentro de um modo de infusão (por exemplo, bombeamento, interrompido, alarmado, etc.). Mediante o processamento do evento de bomba 146, uma FSM 156, 157 ou 158 respectiva pode transitar para um novo estado, criar, atualizar ou eliminar um objeto de contexto e a saída de um evento reportável (uma mensagem de CQI), tal como um evento biomédico reportável 148 ou um evento clínico reportável 149. Em uma modalidade específica da presente revelação, uma lista de eventos clínicos reportáveis é mostrada na Tabela 2 conforme o seguinte:
Figure img0005
Figure img0006
Figure img0007
Tabela 2
[000267] Referindo-se às Figuras 4 e 8, o Ouvinte de CQI 93 da Figura 4 pode executar dentro de cada uma das instalações 82, pode se conectar uma porta de dispositivo (99 na Figura 4 ou 147 da Figura 8) e assinar RCEs de CQI 149 ou os RBEs de CQI 148. O ouvinte de CQI 93 da Figura 4 pode estabelecer uma conexão privada segura com o receptor de CQI 108 no ambiente hospedado 83 (vide Figura 4). Essa conexão pode ser física (conectado continuamente) ou lógica (conexão transiente ao transmitir mensagens).
[000268] A porta de dispositivo 147 pode encaminhar os RCEs 149 ou os RBEs 148 a o ouvinte de CQI 93. O ouvinte de CQI 93 pode garantir a durabilidade da mensagem (isto é, nenhuma mensagem é perdida durante a transmissão devido a congestionamento ou desconexão da rede). Como resultado, o ouvinte de CQI 93 pode: (1) armazenar cada uma das mensagens a ser transmitida para um fila persistente local (para armazenamento em armazenamento temporário); (2) transmitir cada um dos RCEs 149 e/ou dos RBEs 148 a partir da cabeça da fila a o receptor de CQI 108; e/ou (3) remover a mensagem após receber confirmação a partir do receptor de CQI 108.
[000269] O receptor de CQI 108 é executado dentro de um ambiente hospedado dentro de 83. O receptor de CQI 108 ouve e aceita solicitações de conexão de rede seguras a partir de um ou mais ouvintes de CQI 93. O receptor de CQI 108 recebe os RCEs 149 a partir de cada um dos ouvintes de CQI 93 conectados. O receptor de CQI 108 pode garantir a durabilidade de mensagem, então, mediante o recebimento, grava cada um dos RCE 149 no banco de dados 105. O receptor de CQI 108: (1) armazena cada uma das mensagens a ser transmitida para um fila persistente local (para armazenamento em armazenamento temporário); (2) anexa cada uma das mensagens de CQI a partir da cabeça da fila a uma Tabela em um banco de dados de evento de CQI; (3) confirma o recebimento da mensagem a o ouvinte de CQI 93 que envia a mensagem; e (4) remove a mensagem de CQI a partir da fila local (dado que a mesma está seguramente no banco de dados de evento de CQI 105).
[000270] Conforme mencionado anteriormente, o banco de dados de evento de CQI 105 é implantado usando-se uma replicação Mestre- Escravo. Isto é, o banco de dados 105 é o mestre enquanto o banco de dados 106 é o escravo. Com essa abordagem, em algumas modalidades específicas, há duas cópias do banco de dados de evento de CQI com esquemas idênticos. Conforme as transações de inserção, atualização e eliminação são aplicadas ao banco de dados mestre 105, um sistema de gerenciamento de banco de dados (DBMS) dentro do banco de dados 105 grava as alterações em um diário e tem a capacidade de transmitir alterações não divulgadas ao banco de dados escravo 106.
[000271] Cada mensagem de CQI (por exemplo, um RCE) pode pertencer a uma instituição específica. Essa referência de instituição deve coincidir com a instituição que opera o dispositivo médico (por exemplo, um dispositivo médico dentre os dispositivos médicos 101 da Figura 4 ou o dispositivo médico 145 da Figura 8) e que tenha gerado a Biblioteca de Administração de Fármaco (DAL) que é implantada em tal dispositivo. Como resultado, os bancos de dados de CQI 105, 106 podem exigir uma lista de instituições que consista com o banco de dados de DERS 113.
[000272] A Figura 9 mostra um diagrama de estado que ilustra um método 161 da programação de um dispositivo de infusão (por exemplo, dos dispositivos 16 da Figura 1) de acordo com uma modalidade da presente revelação. O método 161 começa com o usuário que tem a capacidade de interagir com a UI do dispositivo.
[000273] A programação de infusão se inicia no estado mostrado como o estado rotulado como "início". O estado 162 é quando a programação de modo básico é usada (por exemplo, quando um dispositivo de exceção de cumprimento de DERS é usado, por exemplo). Após a programação usar um dispositivo de exceção de cumprimento de DERS, o método transiciona ao estado 165 no qual a programação de dose é completa.
[000274] O estado 166 é quando a proteção baseada em DERS é usada e os parâmetros de dose são programados no dispositivo, que transita o estado 165 se nenhuma violação de limite for detectada. Se houver uma violação de limite maleável detectada ou uma violação de limite rigoroso detectada, o método 161 transiciona para o estado 167. Se a mesma for de um limite maleável, o profissional clínico pode: (1) ignorar o limite de software, o que faz com que o método continue para o estado 165; (2) programar os atributos de infusão com finalidade de infusão não alterada, que continua para o estado 165 se nenhuma violação nova for encontrada ou para o estado 167 se uma nova violação for encontrada; ou (3) alterar a finalidade de infusão (medicação, área de cuidado clínico, uso clínico e/ou concentração) que faz com que o método 161 reinicie no estado 166.
[000275] Se um limite rigoroso for detectado, o método transiciona a partir do estado 166 para o estado 167, o que exige que o estado retransiciona de volta para o estado 166 e não permite que o profissional clínico ignore a violação DERS.
[000276] O método de infusão 161 pode ser cancelado durante diversos estados. No estado de programação de modo básico 162, o profissional clínico pode cancelar a infusão antes de a programação ser concluída. No estado de programação DERS 166. o profissional clínico pode cancelar a infusão antes de a programação ser concluída. No estado 167 quando um limite maleável ou violação de limite Rigorosos DERS forem detectados, o profissional clínico pode cancelar a infusão 4.
[000277] Durante o estado 165, o dispositivo médico apresentará um botão de “início de infusão” o qual o profissional de cuidados pode pressionar para transitar para o dispositivo médico para o estado 163, no qual a infusão começa. Um botão suspenso está presente na interface de usuário quando estiver no estado 163 que faz com que o dispositivo seja suspenso quando pressionado, desse modo, transicionando o dispositivo para o estado 164. Um botão de continuação está presente na interface de usuário quando estiver no estado 164 que faz com que o dispositivo retorne para o estado 163 quando pressionado para continuar a terapia. Se um erro fatal (um conjunto pré-determinado de erros) for detectado nos estados 163 e/ou 164, o método 161 transiciona para o estado de encerramento.
[000278] Mediante a conclusão da infusão, a bomba envia uma mensagem de conclusão de infusão para o servidor clínico através da porta de dispositivo. O servidor clínico vincula o evento de conclusão ao registro de prescrição. O servidor clínico formata uma mensagem de auto documentação de IHE e envia essa para uma aplicação de IT de instalação 11 (vide Figura 1), por exemplo, para registrar em um Registro Eletrônico de Administração Médica (“eMar”), para atualizar o Registro Médico Eletrônico (EMR) 17 do paciente e/ou atualizar o sistema de cobrança do hospital para registrar a infusão bem-sucedida da medicação.
[000279] A Figura 10 ilustra um modelo de publicação-assinatura 168 usado pela porta de instalação 21 da Figura 1, pelas aplicações 41, 42, 43, 44 e pela porta de dispositivo 40 na Figura 2 ou na Figura 4 de acordo com uma modalidade da presente revelação.
[000280] O modelo usa um mecanismo de publicação-assinatura 169 que permite que os distribuidores 171 registrem um ou mais tópicos 170 com o mecanismo de publicação-assinatura 169. Uma vez que o tópico 170 é registrado, um ou mais assinantes 172 podem assinar ao tópico 170. Os assinantes 172 podem assinar usando uma assinatura garantida ao tópico 170 em algumas modalidades específicas. Quando um distribuidor dentre os distribuidores 171 divulgar um evento relacionado ao tópico 170, todos os assinantes dentre os assinantes 172 que assinaram ao tópico 170 recebem os dados a partir do mecanismo de publicação-assinatura 169.
[000281] Um distribuidor (dentre os distribuidores 171) pode registrar um ou mais tópicos 170, sendo que cada um dos tópicos pode ser um tópico único. Um ou mais assinantes 172 podem assinar um ou mais tópicos dos tópicos 170 para receber os eventos desses. Quando um distribuidor 171 divulgar um evento em um tópico único (por exemplo, um “primeiro tópico”) dentre os tópicos 170, todos os assinantes do primeiro tópico dentre os tópicos 170 receberão tal evento; os não assinantes do primeiro tópico dos tópicos 170 não receberão tal evento e os assinantes 172 que assinam outros tópicos (por exemplo, um segundo tópico) dentre os tópicos 170, porém não ao primeiro tópico, não receberão o evento enviado que corresponde apenas ao primeiro tópico.
[000282] Os tópicos 170 podem fornecer um nível de indireção que permite que os distribuidores 171 e os assinantes 172 sejam anônimos, em algumas modalidades. O mecanismo de publicação-assinatura 169 permite que a comunicação seja de uma via e assíncrona (por exemplo, uma comunicação “disparar e esquecer”). O mecanismo de publicação- assinatura 169 pode fornecer uma entrega de mensagem durável em ambos os lados. Os tópicos duráveis dentre os tópicos 170 podem garantir que as mensagens não serão perdidas se o mecanismo de publicação-assinatura 169 falhar. As assinaturas duráveis usadas pelos assinantes 172 podem garantir que um assinante 172 não perderá mensagens quando esse não estiver em execução.
[000283] O mecanismo de publicação-assinatura 169 pode ser parte da porta de dispositivo 22, pode ser parte de qualquer outro software dentro da porta de instalação 21 ou pode ser uma aplicação independente da Figura 1. O mecanismo de publicação-assinatura 169 pode ser parte da porta de dispositivo 40, dentro de uma aplicação 41 a 44, ou pode ser uma aplicação independente da Figura 2. O mecanismo de publicação-assinatura 169 pode ser parte da porta de dispositivo 99 da Figura 4, pode ser parte das aplicações 94, 96, 97 ou pode ser uma aplicação independente da Figura 4.
[000284] A Figura 11 ilustra um modelo de registro de capacidade 173 de acordo com uma modalidade da presente revelação. Um fornecedor 176 registra sua capacidade 175 com um registro de capacidade 174. A capacidade 174 pode incluir dois aspectos, que incluem uma interface e um atributo. A interface é a lista de pares de solicitação/resposta e de notificações (em ambas as direções). Os atributos são os parâmetros de acordo de nível de serviço que especificam os limites da qualidade de entrega (por exemplo, tempos de resposta, taxas de erro e políticas de recuperação, despesas, etc.).
[000285] Um iniciador 177 pode se comunicar com o registro de capacidade 174 para encontrar e se associar à capacidade. Portanto, os iniciadores 177 podem solicitar informações a partir dos fornecedores 176 e receber uma resposta. O registro de capacidade 174 pode ser parte da porta de dispositivo 22, pode ser parte de qualquer outro software dentro da porta de instalação 21 ou pode ser uma aplicação independente da Figura 1. O registro de capacidade 174 pode ser parte da porta de dispositivo 40, dentro de uma aplicação 41 a 44, ou pode ser uma aplicação independente da Figura 2. O registro de capacidade 174 pode ser parte da porta de dispositivo 99 da Figura 4, pode ser parte das aplicações 94, 96, 97 ou pode ser uma aplicação independente da Figura 4. O registro de capacidade 174 pode suplementar ou substituir o mecanismo de publicação-assinatura 169 em algumas modalidades específicas.
[000286] A Figura 12 mostra um diagrama de blocos de um sistema 178 para ilustrar as comunicações entre um dispositivo médico 179 e uma porta de dispositivo 185 de acordo com uma modalidade da presente revelação. O dispositivo médico 179 pode utilizar um gerente de comunicação de porta de dispositivo (“DGCM”) 342 para se comunicar com a porta de dispositivo 185. As comunicações podem ser baseadas em serviços de web, em que o dispositivo médico 179 é o cliente e a porta de dispositivo 185 é o servidor de web que usa o transporte de comunicação HTTPS.
[000287] A comunicação está na forma de transações, em que o dispositivo médico 179 invoca os métodos de web hospedados na porta de dispositivo 185 (por exemplo, uma porta de dispositivo médico). O dispositivo médico pode usar uma conexão WiFi 182 que se comunica com a porta de dispositivo 185 que usa um roteador WiFi 183 acoplado a uma rede 184 que é acoplada à porta de dispositivo 185 através de uma conexão Ethernet 186. Em uma modalidade específica, o TCP/IP fornece o protocolo de transporte pela rede 184, o SOAP fornece o formato de mensagem que está em conformidade com o HTTP e o SSL fornece a criptografia/autenticação exigida para garantir a comunicação (HTTPS). Dentro do software 179 de dispositivo médico, o gerente de comunicações gerencia p lado de cliente da comunicação de serviços de web.
[000288] O gerente de comunicações se comunica com a porta de dispositivo 185 através da invocação de um dos métodos de web hospedados na porta de dispositivo 185 usando-se mensagem de SOAP e SSL pelo HTTPS. Isso pode usar uma associação de SOAP 187 para a linguagem de software usada para implantar a interface. Além disso, a associação de SOAP 187 pode ter a capacidade de SSL para fornecer comunicações seguras pelo HTTPS. Um arquivo de linguagem de descrição de serviços de web (“WSDL”) é criado para definir as operações de serviço de web (métodos de web 195) e esquemas exigidos para o servidor de web da porta de dispositivo 185. Um arquivo WSDL pode ser criado para os métodos de web 195 e tipos de dados usados. Usando-se a ferramenta de utilidade do fornecedor de WSDL e de SOAP, os arquivos de código fonte de cliente de SOAP são gerados e adicionados ao software de gerente de comunicações. A fim de que o gerente de comunicações inicie com sucesso uma transação com a porta de dispositivo 185, o seguinte pode ser usado/definido: (1) o OpenSSL 179 é instalado no dispositivo médico 185 (software 181); (2) o nome de hospedeiro e a porta de IP da porta de dispositivo 185 são armazenados na estrutura de dados 192; (3) a estrutura de dados de certificado público 193 de porta de dispositivo 185 reside no dispositivo médico 179; e (4) a chave privada e o certificado público 194 do dispositivo médico 170 residem no dispositivo médico 179.
[000289] A porta de dispositivo 185 é configurada como um servidor de web e os hospedeiros dos métodos de web 195 que os dispositivos remotos (por exemplo, o dispositivo médico 179) acessam a fim de recuperar informações a partir da ou passar informações para a porta de dispositivo 185. Devido ao fato de que o HTTPS é usado para garantir a comunicação, a porta de dispositivo pode usar uma interface de SOAP e de SSL 187. Um arquivo de WSDL pode ser criado para definir as operações de serviço de web (por exemplo, os métodos de web 195) e os tipos de dados exigidos para o servidor de web. Um arquivo WSDL foi criado para os métodos de web 195 e tipos de dados exigidos. Usando-se a ferramenta de utilidade do fornecedor de WSDL e de SOAP, os arquivos de código fonte de servidor de SOAP são gerados e adicionados à porta de dispositivo 185 para a instalação que fornece as funções de porta 188. A fim de que a porta de dispositivo 185 processe uma transação com a porta de dispositivo 179, o seguinte pode ser usado/definido: (1) o OpenSSL 187 (ou software equivalente) é instalado na porta de dispositivo 185 que pode fornecer uma porta de comunicações 189 e a conectividade de rede 191; (2) o certificado público de dispositivo médico 179 pode residir na porta de dispositivo 185 em uma estrutura de dados 190; e/ou (3) a chave privada e o certificado público de porta de dispositivo 185 residem na porta de dispositivo 185 em uma estrutura de dados 190.
[000290] A implantação de serviços da web define a interface de comunicações entre o dispositivo médico 179 e a porta de dispositivo 179 para o propósito de estabelecer comunicação e trocar informações. Essa comunicação é na forma de transações, iniciada invocando-se um método da web 195 hospedado na porta de dispositivo 185. Quatro métodos de web são usados para passar informações entre o dispositivo médico 179 (com o uso do DGCM 342) e a porta de dispositivo 185. Os métodos de web são hospedados na porta de dispositivo 185 e invocados pelo DGCM 342 para iniciar uma transação de troca de informações com a porta de dispositivo 185. Cada método da web pode ser usado para tipos específicos de informações que se movem, como identificado na Tabela 3. Em uma modalidade específica, uma lista dessas transações e métodos de web associados podem ser encontrados na Tabela 3 a seguir:
Figure img0008
Figure img0009
Tabela 3
[000291] A transação de Verificação de Estado de Comunicação é usada para registrar o dispositivo médico 179 com a porta de dispositivo 185, manter comunicação com a porta de dispositivo 185, e para recuperar estado com respeito a informações disponíveis que a porta de dispositivo 185 está mantendo para o dispositivo médico 179. A Verificação de Programa de Infusão de Paciente, Verificação de Instruções de Paciente, Verificação de Dados Escalares de Paciente, Verificação de Informações de Dispositivo, Verificação de Notificação de Alerta, Verificação de Pacote de Software Debian e transações de Verificação de Arquivo de Configuração de DAL são usados para recuperar informações de porta de dispositivo disponível 185 que foram identificadas dentro da resposta de Verificação de Estado de Comunicação anterior da porta de dispositivo 185. As transações de Divulgação de Arquivo de Log de Serviço e Divulgação de Arquivo de Log de Engenharia são usadas para enviar arquivos de log para a porta de dispositivo 185 que foram identificados dentro da resposta de Verificação de Estado de Comunicação anterior da porta de dispositivo 185. A transação de Divulgação de Informações de Log de Infusão para a porta de dispositivo 185 é iniciada sempre que eventos de Log de Infusão disponíveis dentro do dispositivo médico 179 já não tiverem sido enviados para porta de dispositivo 185. Arquivos podem ser transferidos entre o dispositivo médico 179 e a porta de dispositivo como um anexo DIME para a mensagem de SOAP. A transação de Verificação Informações de Tempo é usada para recuperar a hora da porta de dispositivo 185 para sincronização de hora.
[000292] Os métodos de web 184 são usados para recuperar informações da porta de dispositivo 185 e para passar informações para a porta de dispositivo 185. Os métodos de web 184 são mostrados na Tabela 4 com seu Protótipo estilo C como segue:
Figure img0010
[000293] Em algumas modalidades, cada parâmetro passado pode ser uma estrutura de dados ou um int (ou seja, um tipo de dados inteiro de C). Em outras modalidades, qualquer tipo de dados pode ser passado. As declarações de estrutura de dados são mostradas na Figura 13. Todos os ponteiros de membro de estrutura de dados (diferentes de device_Image _T 199, que é uma estrutura de dados requerida pela implantação do SOAP) são para sequências de caracteres terminadas em nulo. A lista de parâmetros dentro do método da web contém um ou mais parâmetros para passar informações para a porta de dispositivo 185 (consultar Figura 12) e um parâmetro para receber informações da porta de dispositivo 185. Os parâmetros de passagem podem ser por valor, por referência, ou por ponteiro. O parâmetro de recepção é sempre o último na lista de parâmetros e é um tipo de dados referenciado (&dataType). Mesmo quando o método da web não tem informações para retornar, o parâmetro de recepção ainda é requerido. Por exemplo, device infusionSendTransaction(..., int &result) e device fileSendTransaction(., int &result) usam “&result” para atender essa exigência.
[000294] Cada método da web tem um valor de retorno que identifica o estado de conclusão da transação para o iniciador. Um conjunto exemplificativo de valores de retorno é fornecido na Tabela 5 como segue:
Figure img0011
[000295] Em referência novamente à Figura 13, os ponteiros de membro do device_Header_T 197 são mostrados e descritos na Tabela 6 a seguir como segue:
Figure img0012
[000296] Os ponteiros de membro do device_InternalStatus _T 198 são mostrados e descritos na tabela 7 ‘como segue:
Figure img0013
[000297] Com referência às Figuras 12 e 13, o device_ClientRequest _T 200 identifica o tipo das informações que o gerenciador de comunicação do dispositivo médico 179 está solicitando da porta de dispositivo 185. Em uma modalidade específica, as solicitações a seguir que usam device_ClientRequest _T 200 são mostradas e descritas na Tabela 8 a seguir
Figure img0014
[000298] O device_GatewayResponse _T 201 fornece a resposta da porta de dispositivo 185 para a solicitação recebida. Uma modalidade exemplificativa de estados (por exemplo, char * state _ptr) e uma descrição dos mesmos são mostradas na Tabela 9 como segue:
Figure img0015
[000299] Char *payload_ptr fornece as informações solicitadas pelo dispositivo médico 179 através do gerenciador de comunicação do dispositivo 179.
[000300] O device_FileData _T 203 identifica o tipo de arquivo que é enviado para a porta de dispositivo 185. Uma modalidade exemplificativa de tipos de arquivos e uma descrição dos mesmos são mostradas na Tabela 10 como segue:
Figure img0016
[000301] O device_FileResponse _T 204 fornece a resposta da porta de dispositivo 184 para a solicitação recebida. Uma modalidade exemplificativa dos estados e uma descrição dos mesmos são mostradas na Tabela 11 como segue:
Figure img0017
[000302] O char *filename_ptr identifica o arquivo transferido para o gerenciador de comunicação de porta de dispositivo 342. The char *payload_ptr do device_InfusionData _T 202 fornece as informações de log de infusão como XML para a porta de dispositivo 185. A carga útil é organizada como elementos de XML em que há um elemento raiz e elementos filhos.
[000303] A Figura 14 mostra um fluxograma que ilustra um método 205 de comunicação entre um dispositivo médico e uma porta de dispositivo de acordo com uma modalidade da presente revelação. Ou seja, o método 205 é uma sequência de transação genérica entre um dispositivo médico (que usa um DGM) e uma porta de dispositivo. O método 205 pode ser usado pelos métodos mostrados nas Figuras 15 a 26 para realizar suas respectivas transações.
[000304] Geralmente, uma transação consiste do DGCM 342 do dispositivo médico invocar um método da web hospedado na porta de dispositivo. Essa ação define uma conexão HTTPS com a porta de dispositivo. Durante o estabelecimento de conexão, a autenticação com o uso de criptografia assimétrica é realizada entre o dispositivo médico e a porta de dispositivo para estabelecer um relacionamento seguro/confiável. Uma vez autenticado, uma sessão SSL é estabelecida e os dois terminais criam uma chave comum e usam criptografia simétrica para passagem de dados. A transação é processada, informações são retornadas, e a conexão HTTPS é fechada. Até três tentativas de transação são tentadas para alcançar uma transação bem- sucedida antes de falhar A. Figura 14 mostra uma modalidade específica, ou seja, método 205, dessa transação.
[000305] O método 205 inclui os atos 206 a 232. O ato 206 entra no método. O ato 207 inicia a autenticação de porta de dispositivo e solicita um certificado. Uma conexão de soquete é estabelecida no ato 223. No ato 224, a porta de dispositivo recebe a solicitação e envia o certificado público para o dispositivo médico. No ato 208, o dispositivo médico valida o certificado público por comparação do mesmo a uma cópia local. No ato 209, o dispositivo médico solicita que a porta de dispositivo comprove sua identidade criptografando dados (por exemplo, dados predeterminados, tais como um número serial ou número de ID da porta de dispositivo). Os dados então são enviados do dispositivo médico para a porta de dispositivo.
[000306] A porta de dispositivo pode então criptografar uma mensagem (por exemplo, um número serial ou ID da porta de dispositivo) com o uso de sua chave privada durante o ato 225 e envia as mensagens criptografadas para o dispositivo médico. No ato 210, a mensagem é descriptografada com o uso de um certificado público da porta de dispositivo.
[000307] O ato 226 inicia uma autenticação de dispositivo médico ao solicitar um certificado, que é recebido pelo dispositivo médico, que envia o certificado público no ato 211 para a porta de dispositivo. No ato 227, a porta de dispositivo validará o certificado comparando-o a uma cópia local. No ato 228, a porta de dispositivo solicita que o dispositivo médico comprove sua identidade criptografando alguns dados (por exemplo, dados predeterminados, tais como um número serial ou número de ID do dispositivo médico).
[000308] No ato 212, o dispositivo médico criptografa dados (por exemplo, os dados predeterminados). Os dados criptografados são enviados para a porta de dispositivo que descriptografa os dados no ato 229. No ato 230, a porta de dispositivo determina se o dispositivo médico é autenticado e no ato 213 o médico determina se a porta de dispositivo está autenticada. Se ambos estiverem autenticados, o ato 214 define uma chave de sessão. Se a porta de dispositivo não puder autenticar o dispositivo médico no ato 230, a transação é terminada no ato 231. Se o dispositivo médico não puder autenticar a porta de dispositivo, o dispositivo médico tentará até três vezes (consultar 219) e a transação será considerada uma falha no ato 220 após três tentativas.
[000309] No ato 215, após a sessão SSL ser estabelecida no ato 214, o dispositivo médico formata uma transação (por exemplo, um método da web) e usa a chave de criptografia simétrica ssl para enviar a transação para a porta de dispositivo. O ato 232 descriptografa o método da web após o mesmo receber o método da web, processar o método da web, e formatar uma resposta. O ato 232 criptografa a resposta (por exemplo, um valor de retorno) que é enviada para o dispositivo médico. O dispositivo médico descriptografa a resposta e examina o valor de retorno no ato 216. No ato 217, o dispositivo médico determinará se o valor de retorno corresponde a uma transação bem- sucedida e declarará uma transação bem-sucedida no ato 218. Se a transação não tiver sido um sucesso, o ato 217 iniciará outra tentativa pelo ato 219.
[000310] A Figura 15 mostra um fluxograma que ilustra um método 233 de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma verificação de estado e comunicação de acordo com uma modalidade da presente revelação. A transação de verificação de estado de comunicação é iniciada periodicamente pelo DGCM 342 para estabelecer comunicação com a porta de dispositivo (que muda de Desconectado para Conectado), para manter comunicação com a porta de dispositivo (mantém Conectado, muda para Desconectado), e para recuperar informações de estado com respeito a informações disponíveis que a porta de dispositivo está mantendo para o dispositivo médico.
[000311] O método 233 inclui os atos 234-238 e 240-241. O ato 234 inicia a verificação de estado a cada 60 segundos. O ato 234 recebe a solicitação de verificação de estado (por exemplo, o DGCM 342 recebe a mesma). O ato 236 envia as solicitações e define uma conexão HTTPS no ato 241. A Tabela 239 mostra a lista de acesso de dispositivos médicos que podem acessar a porta de dispositivo.
[000312] No ato 240, a porta de dispositivo determinará se o dispositivo médico está na lista de acesso 239 e formulará uma resposta que inclui as informações que estão disponíveis para o dispositivo médico. A resposta é enviada para o dispositivo médico que examina a mesma no ato 237.
[000313] A porta de dispositivo define o Estado de Resposta para REJEITADO se o dispositivo médico não for um membro da lista de acesso do dispositivo 248. A porta de dispositivo define as informações disponíveis para NENHUMA se as mesmas não estiverem disponíveis para o dispositivo médico, e caso contrário define o elemento apropriado dentro da Carga Útil da Resposta baseada em XML para os valores na Tabela 12 como segue:
Figure img0018
[000314] A Figura 16 mostra um fluxograma que ilustra um método 242 de comunicação entre um dispositivo médico e uma porta de dispositivo para sincronizar seus respectivos relógios de acordo com uma modalidade da presente revelação. O método 242 implanta a transação de sincronização de hora periodicamente pelo DGCM do dispositivo médico para recuperar a data e hora atuais da porta de dispositivo. As informações são usadas para atualizar o relógio em tempo real do dispositivo médico para que o mesmo corresponda ao relógio em tempo real da porta de dispositivo.
[000315] O ato 243 inicia periodicamente (por exemplo, a cada 90 minutos) uma solicitação de HORA. A solicitação é formatada como um método da web no ato 245 que comunica a mesma para a porta de dispositivo estabelecendo uma conexão HTTPS no ato 250. No ato 249, é formatada uma resposta, que inclui uma carga útil que indica a hora da porta de dispositivo. Se o dispositivo médico não for um membro da lista de acesso do dispositivo da porta de dispositivo 248, o estado é definido como REJEITADO, caso contrário o mesmo é definido como DISPONÍVEL. Se o estado for definido como DISPONÍVEL, a porta de dispositivo formata a carga útil da resposta como o número de segundos passados desde 1 de janeiro de 1970. A porta de dispositivo comunica a resposta através de uma conexão HTTPS que é fechada no ato 247 após a transmissão. O ato 246 examina a resposta pela porta de dispositivo.
[000316] A Figura 17 mostra um fluxograma que ilustra um método 251 de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de infusão de paciente de acordo com uma modalidade da presente revelação. A transação de verificação de programa de infusão de paciente implantada como método 215 é iniciada para recuperar o programa de infusão de paciente disponível a partir da porta de dispositivo. O programa de infusão de paciente pode ser um ou mais parâmetros de infusão, por exemplo, vazão, dose a ser entregue, fármaco a ser infundido, etc. A transação é iniciada sempre que uma INFUSÃO DISPONÍVEL tiver sido recebida de uma transação de verificação de estado de comunicação prévia, que dispara o método 251.
[000317] O ato 252 recebe o gatilho. O ato 253 inicia uma solicitação de “PROGRAMA” que é formatada em um método da web no ato 254. O método da web é transmitido para a porta de dispositivo através de uma conexão HTTPS que é estabelecida no ato 259. O ato 258 processa o método da web e formata uma resposta. A porta de dispositivo define o estado da resposta para REJEITADO se o dispositivo médico não for uma parte da lista de acesso 257. Se um Programa de infusão de paciente não estiver disponível para o dispositivo médico, o estado é definido como NENHUM, caso contrário, o mesmo é definido como DISPONÍVEL. O programa de infusão pode ser parte da carga útil ou referenciar um programa de infusão baseado em texto. A resposta é comunicada ao dispositivo médico que examina a resposta da transação no ato 255. O ato 256 fecha a conexão HTTPS após a resposta ser transmitida.
[000318] A Figura 18 mostra um fluxograma que ilustra um método 260 de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de instruções de paciente de acordo com uma modalidade da presente revelação. Essa transação de verificação de instruções de paciente é iniciada para recuperar as instruções de paciente disponíveis a partir da porta de dispositivo. A transação (mostrada como método 260) é iniciada sempre que uma INSTRUÇÕES DISPONÍVEL tiver sido recebida de uma transação de verificação de estado de comunicação prévia (por exemplo, consultar a Figura 15).
[000319] No ato 261, o método 260 é iniciado. No ato 262, a solicitação de consulta de instrução de paciente é iniciada, e no ato 263, um método da web é formatado e enviado para a porta de dispositivo com o uso de uma conexão HTTPS que é estabelecida no ato 268. No ato 267, a porta de dispositivo formata uma resposta que é enviada para o dispositivo médico. Se o dispositivo médico não for um membro da lista de acesso da porta de dispositivo 266, o estado é definido como REJEITADO. Se o dispositivo médico for uma parte da lista de acesso da porta 266 e nenhuma instrução de paciente estiver disponível, o estado é definido como NENHUM. Se o dispositivo médico for uma parte da lista de acesso da porta 266 e instruções de paciente estiverem disponíveis, o estado é definido como DISPONÍVEL e a porta de dispositivo formata a carga útil da resposta para referência ou inclui o texto baseado em instruções de paciente. Após a resposta ser enviada, a conexão HTTPS é fechada no ato 265. No ato 264, a resposta é examinada.
[000320] A Figura 19 mostra um fluxograma que ilustra um método 269 de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de dados escalares de paciente de acordo com uma modalidade da presente revelação. A transação de verificação de dados escalares de paciente (implantada pelo método 269) é iniciada pelo dispositivo médico para recuperar os dados escalares de paciente disponíveis a partir da porta de dispositivo. A transação é iniciada sempre que um DADOS DISPONÍVEIS tiver sido recebido de uma transação de verificação de estado de comunicação prévia.
[000321] No ato 270, o método 269 é disparado. No ato 271, é iniciada a solicitação que é formatada como um método da web no ato 272. O método da web é comunicado através de uma conexão HTTPS estabelecida no ato 277 do dispositivo médico para a porta de dispositivo. A porta de dispositivo formata uma resposta para o ato 276. Se o dispositivo médico não for um membro da lista de acesso do dispositivo da porta de dispositivo 275 o estado é definido como REJEITADO. Se o dispositivo médico for um membro da lista de acesso do dispositivo da porta de dispositivo 275 e os dados escalares relacionados ao paciente não estiverem disponíveis, o estado é definido como NENHUM. Se o dispositivo médico for um membro da lista de acesso do dispositivo da porta de dispositivo 275 e os dados escalares relacionados ao paciente estiverem disponíveis, o estado é definido como DISPONÍVEL e a carga útil da resposta inclui ou referencia dados escalares baseados em texto. Os dados escalares de paciente podem ser quaisquer dados relacionados a um paciente, tal como paciente idade, peso, alergias, sexo, altura, etc. A resposta é comunicada e no ato 274, a conexão HTTPS é fechada. No ato 273, o dispositivo médico examina (por exemplo, processa e usa) a resposta.
[000322] A Figura 20 mostra um fluxograma que ilustra um método 278 de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma sequência de transação de informações de dispositivo de acordo com uma modalidade da presente revelação. A transação de verificação de informações de dispositivo (implantada como método 278) é iniciada para recuperar as informações de dispositivo disponíveis a partir da porta de dispositivo. A transação é iniciada sempre que um DISPOSITIVO DISPONÍVEL tiver sido recebido de uma transação de verificação de estado de comunicação prévia.
[000323] No ato 279, o método 278 é iniciado. No ato 280, a solicitação de consulta de informações de dispositivo é iniciada e no ato 281 o método da web é formatado. O método da web é comunicado à porta de dispositivo através de uma conexão HTTPS que é estabelecida no ato 286. No ato 285, uma resposta é formatada. Se o dispositivo médico não for um membro da lista de acesso do dispositivo da porta de dispositivo 275 o estado é definido como REJEITADO. Se o dispositivo médico for um membro da lista de acesso do dispositivo da porta de dispositivo 275 e as informações de dispositivo não estiverem disponíveis, o estado é definido como NENHUM. Se o dispositivo médico for um membro da lista de acesso do dispositivo da porta de dispositivo 275 e as informações de dispositivo estiverem disponíveis, o estado é definido como DISPONÍVEL e a carga útil da resposta inclui ou referencia informações de dispositivo baseadas em texto. Em algumas modalidades, as informações de dispositivo baseadas em texto podem ser quaisquer informações relacionadas à porta de dispositivo ou ao dispositivo médico. A resposta é comunicada ao dispositivo médico e a conexão HTTPS é fechada no ato 283. No ato 282 o dispositivo médico examina a resposta.
[000324] A Figura 21 mostra um fluxograma que ilustra um método 287 de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de notificação de alerta de acordo com uma modalidade da presente revelação. A transação de verificação de notificação de alerta (implantada pelo método 287) é iniciada para recuperar as notificações de alerta disponíveis a partir da porta de dispositivo. A transação é iniciada sempre que uma NOTIFICAÇÃO DISPONÍVEL tiver sido recebida a partir de uma transação de verificação de estado de comunicação prévia.
[000325] No ato 288, o método 287 é iniciado. No ato 289, o Notificação de Alerta solicitação de consulta é iniciada e no ato 295 o método da web é formatado. O método da web é comunicado à porta de dispositivo através de uma conexão HTTPS que é estabelecida no ato 295. No ato 294, uma resposta é formatada. Se o dispositivo médico não for um membro da lista de acesso do dispositivo da porta de dispositivo 275 o estado é definido como REJEITADO. Se o dispositivo médico for um membro da lista de acesso do dispositivo da porta de dispositivo 275 e uma Notificação de Alerta não estiver disponível, o estado é definido como NENHUM. Se o dispositivo médico for um membro da lista de acesso do dispositivo da porta de dispositivo 275 e uma Notificação de Alerta estiver disponível, o estado é definido como DISPONÍVEL e a carga útil da resposta inclui ou referencia notificações de alerta à base de texto. Em algumas modalidades, a notificação de alerta à base de texto pode representar quaisquer informações relacionadas a um alerta da porta de dispositivo ou do dispositivo médico. A resposta é comunicada ao dispositivo médico e a conexão HTTPS é fechada no ato 295. No ato 291 o dispositivo médico examina a resposta.
[000326] A Figura 22 mostra um fluxograma que ilustra um método 296 de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de verificação de pacote de software (por exemplo, um Pacote de Software Debian) (implantada como método 296) de acordo com uma modalidade da presente revelação. A transação de Verificação de Pacote de Software é iniciada para recuperar o pacote de software disponível a partir da porta de dispositivo. A transação é iniciada sempre que um SOFTWARE DISPONÍVEL tiver sido recebida a partir de uma transação de Verificação de estado de Comunicação prévia.
[000327] No ato 297, o método 269 é disparado. No ato 298, a solicitação é iniciada que é formatada como um método da web no ato 299. O método da web é comunicado através de uma conexão HTTPS estabelecida no ato 304 a partir do dispositivo médico até a porta de dispositivo. A porta de dispositivo formata uma resposta para ato 303. Se o dispositivo médico não for um membro da lista de acesso do dispositivo da porta de dispositivo 275 o estado é definido como REJEITADO. Se o dispositivo médico for um membro da lista de acesso do dispositivo da porta de dispositivo 275 e o software pacote não estiver disponível, o estado é definido como NENHUM. Se o dispositivo médico for um membro da lista de acesso do dispositivo da porta de dispositivo 275 e o software pacote estiver disponível, o estado é definido como DISPONÍVEL e a carga útil da resposta inclui (ou referencia) um arquivo de pacote de software (por exemplo, com o uso de DIME). A resposta é comunicada e no ato 301, a conexão HTTPS é fechada. No ato 300, o dispositivo médico examina (por exemplo, processa e usa) a resposta.
[000328] A Figura 23 mostra um fluxograma que ilustra um método 305 de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de verificação de arquivo de configuração de DAL de acordo com uma modalidade da presente revelação. A transação de verificação de arquivo de configuração de DAL (implantada como método 305) é iniciada para recuperar o arquivo de DAL disponível a partir da porta de dispositivo. A transação é iniciada sempre que um DAL DISPONÍVEL tiver sido recebido a partir de uma transação de verificação de estado de comunicação prévia.
[000329] O ato 306 inicia o método 305. A solicitação é iniciada no ato 306, e a solicitação é formatada como um método da web no ato 308. O dispositivo médico comunica o método da web para a porta de dispositivo estabelecendo-se uma conexão HTTPS no ato 313. No ato 312, uma resposta é formatada. Se o dispositivo médico não for um membro da lista de acesso do dispositivo da porta de dispositivo 311, o estado é definido como REJEITADO, caso contrário o mesmo é definido como DISPONÍVEL. Se o estado for definido como DISPONÍVEL, a porta de dispositivo formata a carga útil da resposta para incluir o Arquivo de Configuração de DAL (que pode ser anexado ao uso de DIME). A resposta é comunicada ao dispositivo médico e no ato 310, a conexão HTTPS é fechada. O ato 309 examina a resposta pela porta de dispositivo. O novo arquivo de DAL pode então ser instalado no dispositivo médico.
[000330] A Figura 24 mostra um fluxograma que ilustra um método 314 de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de Divulgação de Log de Serviço de acordo com uma modalidade da presente revelação. A transação de Divulgação de Log de Serviço (implantada como método 314) é iniciada para enviar o Log de Serviço para a porta de dispositivo. A transação é iniciada sempre que uma SOLICITAÇÃO DE LOG DE SERVIÇO tiver sido recebida a partir de uma transação de verificação de estado de comunicação prévia.
[000331] O ato 315 recebe o gatilho e inicia o método 314. O ato 316 inicia a divulgação de Log de Serviço que é formatada em um método da web no ato 317. O método da web é transmitido para a porta de dispositivo através de uma conexão HTTPS que é estabelecida no ato 322. O ato 321 processa o método da web e formata uma resposta. A porta de dispositivo pode escrever as informações para um arquivo de log ou comunicar a Divulgação de Log de Serviço como uma mensagem de CQI e enviá-la para serviços de nuvem (conforme descrito acima). A resposta é comunicada ao dispositivo médico que examina a resposta da transação no ato 317 (por exemplo, examinando-se o valor de retorno para determinar se a mesma foi uma Divulgação de Log de Serviço bem-sucedida). O ato 319 fecha a conexão HTTPS após a resposta ser transmitida.
[000332] A Figura 25 mostra um fluxograma que ilustra um método 232 de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de Divulgação de Log de Engenharia de acordo com uma modalidade da presente revelação. A transação de Divulgação de Log de Engenharia é iniciada para enviar o Log de Engenharia para a porta de dispositivo. A transação é iniciada sempre que uma SOLICITAÇÃO DE LOG DE ENGENHARIA tiver sido recebida a partir de uma transação de verificação de estado de comunicação prévia.
[000333] O ato 324 recebe o gatilho e inicia o método 323. O ato 325 inicia a Divulgação de Log de Engenharia que é formatada em um método da web no ato 326. O método da web é transmitido para a porta de dispositivo através de uma conexão HTTPS que é estabelecida no ato 331. O ato 330 processa o método da web e formata uma resposta. Se o dispositivo médico for um dispositivo médico autorizado como indicado pela lista de acesso 239, a porta de dispositivo pode escrever as informações para um arquivo de log ou comunicar a Divulgação de Log de Serviço como uma mensagem de CQI mensagem e enviá-la para serviços de nuvem (conforme descrito acima). A resposta é comunicada ao dispositivo médico que examina a resposta da transação no ato 327 (por exemplo, examinando-se o valor de retorno para determinar se a mesma foi uma Divulgação de Log de Engenharia bem-sucedida). O ato 328 fecha a conexão HTTPS após a resposta ser transmitida.
[000334] A Figura 26 mostra um fluxograma que ilustra um método 332 de comunicação entre um dispositivo médico e uma porta de dispositivo para realizar uma transação de Divulgação de Log de Infusão de acordo com uma modalidade da presente revelação. A transação de divulgação de Log de Infusão (implantada como método 332) é iniciada para enviar informações de evento de infusão formatadas em XML para a porta de dispositivo. A transação é iniciada sempre que informações de evento de infusão estiverem disponíveis, que não tenham sido enviadas anteriormente para o dispositivo gerenciador. O DGCM 342 marca a gravação como entregue se a transação for bem-sucedida.
[000335] O ato 333 recebe o gatilho e inicia o método 332. O ato 334 inicia a Divulgação de Log de Infusão que é formatada em um método da web no ato 335. O método da web é transmitido para a porta de dispositivo através de uma conexão HTTPS que é estabelecida no ato 340. O ato 339 processa o método da web e formata uma resposta. A porta de dispositivo pode escrever as informações para um arquivo de log ou comunicar a Divulgação de Log de Infusão como uma mensagem de CQI e enviá-la para os serviços de nuvem (conforme descrito acima). A resposta é comunicada ao dispositivo médico que examina a resposta da transação no ato 336 (por exemplo, examinando-se o valor de retorno para determine se a mesma foi uma Divulgação de Log de Infusão bem-sucedida). O ato 337 fecha a conexão HTTPS após a resposta ser transmitida.
[000336] Várias alternativas e modificações podem ser concebidas por aqueles indivíduos versados na técnica sem se afastar da revelação. Consequentemente, a presente revelação se destina a abranger todas essas alternativas, modificações e variâncias. Adicionalmente, enquanto diversas modalidades da presente revelação foram mostradas nos desenhos e/ou discutidas no presente documento, não é pretendido que a revelação seja limitada às mesmas, já que é pretendido que a revelação seja tão ampla em escopo quanto a técnica permitir e que a revelação seja lida da mesma forma. Portanto, a descrição acima não deveria ser interpretada como limitadora, mas meramente como exemplificações de modalidades particulares. E, aqueles indivíduos versados na técnica irão prever outras modificações dentro do escopo e espírito das reivindicações anexas ao mesmo. Outros elementos, etapas, métodos e conjuntos de procedimentos que são insubstancialmente diferentes daqueles descritos acima e/ou nas reivindicações anexas também são destinados a estarem abrangidos no escopo da revelação.
[000337] As modalidades mostradas nos desenhos são apresentadas somente para demonstrar determinados exemplos da revelação. E, os desenhos descritos são somente ilustrativos e são não limitadores. Nos desenhos, para propósitos ilustrativos, o tamanho de alguns dos elementos pode ser exagerado e não desenhados a uma escala particular. Adicionalmente, os elementos mostrados dentro dos desenhos que têm os mesmos números podem ser elementos idênticos ou podem ser elementos semelhantes, dependendo do contexto.
[000338] Quando o termo “que compreende” é usado na presente descrição e reivindicações, o mesmo não exclui outros elementos ou etapas. Quando um artigo indefinido ou definido é usado para se referir a um nome no singular, por exemplo, “um”, “uma”, “o” ou “a”, o mesmo inclui um plural daquele nome a menos que algo seja especificamente declarado. Por conseguinte, o termo “que compreende” não deveria ser interpretado como sendo restrito aos itens listados posteriormente; o mesmo não exclui outros elementos ou etapas, e assim o escopo da expressão “um dispositivo que compreende itens A e B” não deveria ser limitado a dispositivos quer consistem somente nos componentes A e B. Essa expressão significa que, em relação à presente revelação, os únicos componentes relevantes do dispositivo são A e B.
[000339] Além disso, os termos “primeiro”, “segundo”, “terceiro”, e similares, sejam usados na descrição ou nas reivindicações, são fornecidos para distinguir entre elementos semelhantes e não necessariamente para descrever uma ordem sequencial ou cronológica. Deve ser compreendido que os termos assim usados são intercambiáveis em circunstâncias adequadas (salvo revelado claramente em contrário) e que as modalidades da revelação descrita no presente documento têm a capacidade de operação em outras sequências e/ou disposições do que são descritas ou ilustradas no presente documento.

Claims (17)

1. Sistema para cuidado eletrônico do paciente, o sistema caracterizado pelo fato de que compreende: uma rede; uma porta de instalação (21) que compreende uma porta de dispositivo (22) e um servidor clínico e configurada para fornecer um serviço de publicação-assinatura para um aplicativo; uma porta de dispositivo (22) configurada para execução pela porta de instalação (21), a porta de dispositivo (22) é configurada para se comunicar através da rede fornecendo um serviço da web; um dispositivo médico (26) em comunicação operacional com a rede, em que o dispositivo médico (26) é configurado para se comunicar com a porta de dispositivo (22) com o uso de serviço da web; e um mecanismo de publicação-assinatura (169) configurado para fornecer o serviço de publicação-assinatura para comunicação entre uma pluralidade de aplicativos que incluem a porta de dispositivo (22), a pluralidade de aplicativos sendo executada dentro da porta de instalação (21), em que apenas o dispositivo médico (26) inicia comunicações com a porta de dispositivo (22) pelo uso de um método de web do serviço da web, em que o dispositivo médico (26) inicia as comunicações com a porta de dispositivo (22) usando o serviço da web de acordo com uma periodicidade predeterminada para solicitar uma carga útil de resposta, em que, em resposta à comunicação iniciada a porta de dispositivo (22) formata a carga útil da resposta que compreende uma disponibilidade de uma atualização de software, uma disponibilidade de um tipo de dados consultável e uma pluralidade de estados de solicitação de corrente, em que cada estado de solicitação de corrente indica uma solicitação para que o dispositivo médico (26) transmita um registro para a porta de dispositivo (22), em que a porta de dispositivo (22) comunica a carga útil da resposta ao dispositivo médico (26) em resposta à comunicação iniciada pelo dispositivo médico (26), em que o dispositivo médico (26) transmite o registro solicitado na pluralidade de estados de solicitação de corrente para a porta de dispositivo (22), em que a porta de dispositivo (22) é configurada para registrar um tópico usando o serviço de publicação-assinatura, em que o tópico é um tópico de evento clínico reportável e a porta de dispositivo (22) reformata um evento de dispositivo médico (26) recebido através do serviço da web em um evento clínico reportável que pode ser recebido por um assinante no tópico através do mecanismo de publicação-assinatura (169), e em que o servidor clínico é configurado para iniciar um fluxo de trabalho de autoprogramação, o fluxo de trabalho de autoprogramação compreendendo: identificar o dispositivo médico (26) como correspondente a um paciente alvo; enviar uma mensagem de comando ao dispositivo médico (26) para carregar uma prescrição; o dispositivo médico (26) reconhecendo a receita da prescrição e exibindo uma notificação; o dispositivo médico (26) confirmando que o medicamento corresponde à prescrição, e 1. dispositivo médico (26) enviando uma mensagem ao servidor clínico através da porta de dispositivo (22).
2. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que a rede é uma rede baseada em TCP/IP.
3. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que a porta de dispositivo (22) é um servidor da web do serviço da web e o dispositivo médico (26) é um cliente do serviço da web.
4. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda uma API de integração configurada para execução pela porta de instalação (21), em que a API de integração é configurada para assinar o tópico e comunicar um evento recebido pela assinatura no tópico para pelo menos um servidor externo.
5. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que o dispositivo médico (26) comunica o evento de dispositivo médico (26) através da rede com o uso de serviço da web.
6. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda um ouvinte de aperfeiçoamento com qualidade contínua configurado para execução pela porta de instalação (21), em que: o ouvinte de aperfeiçoamento com qualidade contínua assina um tópico de evento biomédico reportável e um tópico de evento clínico reportável, o aperfeiçoamento com qualidade contínua é configurado para comunicar um evento biomédico reportável recebido pela assinatura no tópico de evento biomédico reportável para um banco de dados externo, e o aperfeiçoamento com qualidade contínua é configurado para comunicar um evento clínico reportável recebido pela assinatura no tópico de evento clínico reportável para um banco de dados externo.
7. Sistema, de acordo com a reivindicação 6, caracterizado pelo fato de que o banco de dados externo registra pelo menos um dentre o evento biomédico reportável e o evento clínico reportável.
8. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda um gerenciador de dispositivo (24) executável na porta de instalação (21), em que o gerenciador de dispositivo (24) é configurado para manter uma lista de dispositivos médicos (26) incluindo o dispositivo médico (26).
9. Sistema, de acordo com a reivindicação 8, caracterizado pelo fato de que a lista dos dispositivos médicos (26) inclui uma lista de números em série correspondente à lista de dispositivos médicos (26).
10. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda um cliente de monitoramento em comunicação operacional com o dispositivo médico (26) através da rede para receber informações de estado a partir do mesmo.
11. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que a porta de dispositivo (22) publica um tópico de evento de dispositivo médico (26), em que o sistema compreende ainda uma aplicação de dispositivo (151) configurada para execução na porta de instalação (21) e configurada para assinar ao tópico de evento de dispositivo médico (26), em que a aplicação de dispositivo (151) publica um tópico de mensagem de Aperfeiçoamento de Qualidade Contínuo (“CQI”), em que a aplicação de dispositivo (151) é configurada para receber um evento a partir da assinatura ao tópico de evento de dispositivo médico (26) e publicar o evento como uma mensagem CQI através do tópico de mensagem de CQI, em que o dispositivo médico (26) é configurado para gerar o evento através do uso de um método web do serviço da web e em que a pluralidade de aplicações inclui a aplicação de dispositivo (151).
12. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de que a porta de dispositivo (22) assina o tópico de mensagem de CQI para receber a mensagem de CQI.
13. Sistema, de acordo com a reivindicação 12, caracterizado pelo fato de que compreende ainda um ouvinte de CQI configurado para execução pela porta de instalação (21), em que o ouvinte de CQI é assinado pelo tópico de mensagem de CQI para receber a mensagem de CQI.
14. Sistema, de acordo com a reivindicação 13, caracterizado pelo fato de que o ouvinte de CQI comunica a mensagem de CQI para um banco de dados externo.
15. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de que a mensagem de CQI é um dentre um evento biomédico reportável e um evento clínico reportável.
16. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende ainda um cliente de monitoramento configurado para se comunicar de modo operativo com o dispositivo médico (26).
17. Sistema, de acordo com a reivindicação 16, caracterizado pelo fato de que o cliente de monitoramento se comunica com o dispositivo médico (26) assinando o tópico de mensagem de CQI.
BR112015014999-5A 2012-12-21 2013-12-20 Sistema para cuidado eletrônico do paciente BR112015014999B1 (pt)

Applications Claiming Priority (20)

Application Number Priority Date Filing Date Title
USPCT/US12/71490 2012-12-21
US13/723,244 US9151646B2 (en) 2011-12-21 2012-12-21 System, method, and apparatus for monitoring, regulating, or controlling fluid flow
US13/723,235 US9400873B2 (en) 2011-12-21 2012-12-21 System, method, and apparatus for dispensing oral medications
PCT/US2012/071490 WO2013096909A2 (en) 2011-12-21 2012-12-21 System, method, and apparatus for infusing fluid
US13/724,568 US9295778B2 (en) 2011-12-21 2012-12-21 Syringe pump
US13/723,239 US10108785B2 (en) 2010-01-22 2012-12-21 System, method, and apparatus for electronic patient care
US13/723,251 2012-12-21
PCT/US2012/071112 WO2013096713A2 (en) 2011-12-21 2012-12-21 System, method, and apparatus for estimating liquid delivery
US13/724,568 2012-12-21
US13/723,253 US11210611B2 (en) 2011-12-21 2012-12-21 System, method, and apparatus for electronic patient care
PCT/US2012/071131 WO2013096718A2 (en) 2011-12-21 2012-12-21 System, method, and apparatus for dispensing oral medications
US13/723,238 US9759369B2 (en) 2011-12-21 2012-12-21 System, method, and apparatus for clamping
PCT/US2012/071142 WO2013096722A2 (en) 2011-12-21 2012-12-21 System, method, and apparatus for monitoring, regulating, or controlling fluid flow
USPCT/US12/71142 2012-12-21
US13/723,251 US9636455B2 (en) 2011-12-21 2012-12-21 System, method, and apparatus for estimating liquid delivery
US13/725,790 US9677555B2 (en) 2011-12-21 2012-12-21 System, method, and apparatus for infusing fluid
US13/723,242 US10911515B2 (en) 2012-05-24 2012-12-21 System, method, and apparatus for electronic patient care
US13/836,497 US10242159B2 (en) 2010-01-22 2013-03-15 System and apparatus for electronic patient care
US13/836,497 2013-03-15
PCT/US2013/076851 WO2014100557A2 (en) 2012-12-21 2013-12-20 System and apparatus for electronic patient care

Publications (2)

Publication Number Publication Date
BR112015014999A2 BR112015014999A2 (pt) 2017-07-11
BR112015014999B1 true BR112015014999B1 (pt) 2021-11-09

Family

ID=50979402

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112015014999-5A BR112015014999B1 (pt) 2012-12-21 2013-12-20 Sistema para cuidado eletrônico do paciente

Country Status (11)

Country Link
EP (2) EP3567595A1 (pt)
JP (6) JP6321676B2 (pt)
CN (3) CN108630308B (pt)
AU (6) AU2013361156B2 (pt)
BR (1) BR112015014999B1 (pt)
CA (2) CA2896063C (pt)
MX (1) MX356990B (pt)
NZ (2) NZ709291A (pt)
RU (1) RU2015129799A (pt)
SG (3) SG11201504861SA (pt)
WO (1) WO2014100557A2 (pt)

Families Citing this family (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9759369B2 (en) 2011-12-21 2017-09-12 Deka Products Limited Partnership System, method, and apparatus for clamping
US9151646B2 (en) 2011-12-21 2015-10-06 Deka Products Limited Partnership System, method, and apparatus for monitoring, regulating, or controlling fluid flow
US11881307B2 (en) 2012-05-24 2024-01-23 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US9295778B2 (en) 2011-12-21 2016-03-29 Deka Products Limited Partnership Syringe pump
US9677555B2 (en) 2011-12-21 2017-06-13 Deka Products Limited Partnership System, method, and apparatus for infusing fluid
US11210611B2 (en) 2011-12-21 2021-12-28 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US9808572B2 (en) 2010-01-22 2017-11-07 Deka Products Limited Partnership System, method and apparatus for clamping
US9518958B2 (en) 2012-12-18 2016-12-13 Deka Products Limited Partnership System, method, and apparatus for detecting air in a fluid line using active rectification
US11164672B2 (en) 2010-01-22 2021-11-02 Deka Products Limited Partnership System and apparatus for electronic patient care
US20110313789A1 (en) 2010-01-22 2011-12-22 Deka Products Limited Partnership Electronic patient monitoring system
US11244745B2 (en) 2010-01-22 2022-02-08 Deka Products Limited Partnership Computer-implemented method, system, and apparatus for electronic patient care
US9400873B2 (en) 2011-12-21 2016-07-26 Deka Products Limited Partnership System, method, and apparatus for dispensing oral medications
US10453157B2 (en) 2010-01-22 2019-10-22 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11227687B2 (en) 2010-01-22 2022-01-18 Deka Products Limited Partnership System, method, and apparatus for communicating data
US9744300B2 (en) 2011-12-21 2017-08-29 Deka Products Limited Partnership Syringe pump and related method
US10911515B2 (en) 2012-05-24 2021-02-02 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US9789247B2 (en) 2011-12-21 2017-10-17 Deka Products Limited Partnership Syringe pump, and related method and system
US9636455B2 (en) 2011-12-21 2017-05-02 Deka Products Limited Partnership System, method, and apparatus for estimating liquid delivery
US9488200B2 (en) 2010-01-22 2016-11-08 Deka Products Limited Partnership System, method, and apparatus for clamping
US10655779B2 (en) 2011-12-21 2020-05-19 Deka Products Limited Partnership System, method, and apparatus for clamping
US10228683B2 (en) 2011-12-21 2019-03-12 Deka Products Limited Partnership System, method, and apparatus for monitoring, regulating, or controlling fluid flow
US10082241B2 (en) 2011-12-21 2018-09-25 Deka Products Limited Partnership System, method, and apparatus for clamping
US9675756B2 (en) 2011-12-21 2017-06-13 Deka Products Limited Partnership Apparatus for infusing fluid
US10722645B2 (en) 2011-12-21 2020-07-28 Deka Products Limited Partnership Syringe pump, and related method and system
US9724466B2 (en) 2011-12-21 2017-08-08 Deka Products Limited Partnership Flow meter
US11649924B2 (en) 2011-12-21 2023-05-16 Deka Products Limited Partnership System, method, and apparatus for clamping
US9746094B2 (en) 2011-12-21 2017-08-29 Deka Products Limited Partnership Flow meter having a background pattern with first and second portions
US9435455B2 (en) 2011-12-21 2016-09-06 Deka Products Limited Partnership System, method, and apparatus for monitoring, regulating, or controlling fluid flow
US11295846B2 (en) 2011-12-21 2022-04-05 Deka Products Limited Partnership System, method, and apparatus for infusing fluid
US10563681B2 (en) 2011-12-21 2020-02-18 Deka Products Limited Partnership System, method, and apparatus for clamping
US9746093B2 (en) 2011-12-21 2017-08-29 Deka Products Limited Partnership Flow meter and related system and apparatus
US11217340B2 (en) 2011-12-21 2022-01-04 Deka Products Limited Partnership Syringe pump having a pressure sensor assembly
US10488848B2 (en) 2011-12-21 2019-11-26 Deka Products Limited Partnership System, method, and apparatus for monitoring, regulating, or controlling fluid flow
JP6401183B2 (ja) 2012-12-21 2018-10-03 デカ・プロダクツ・リミテッド・パートナーシップ データ通信のためのシステム、方法及び装置
US9759343B2 (en) 2012-12-21 2017-09-12 Deka Products Limited Partnership Flow meter using a dynamic background image
USD736370S1 (en) 2013-06-11 2015-08-11 Deka Products Limited Partnership Medical pump
USD767756S1 (en) 2013-06-11 2016-09-27 Deka Products Limited Partnership Medical pump
USD735319S1 (en) 2013-06-11 2015-07-28 Deka Products Limited Partnership Medical pump
US9719964B2 (en) 2013-07-31 2017-08-01 Deka Products Limited Partnership System, method, and apparatus for bubble detection in a fluid line using a split-ring resonator
USD749206S1 (en) 2013-11-06 2016-02-09 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
USD745661S1 (en) 2013-11-06 2015-12-15 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
USD752209S1 (en) 2013-11-06 2016-03-22 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
USD751690S1 (en) 2013-11-06 2016-03-15 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
USD751689S1 (en) 2013-11-06 2016-03-15 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
USD760782S1 (en) 2013-12-20 2016-07-05 Deka Products Limited Partnership Display screen of a medical pump with a graphical user interface
USD760288S1 (en) 2013-12-20 2016-06-28 Deka Products Limited Partnership Medical pump display screen with transitional graphical user interface
USD758399S1 (en) 2013-12-20 2016-06-07 Deka Products Limited Partnership Display screen with graphical user interface
USD756386S1 (en) 2013-12-20 2016-05-17 Deka Products Limited Partnership Display screen with graphical user interface
USD760289S1 (en) 2013-12-20 2016-06-28 Deka Products Limited Partnership Display screen of a syringe pump with a graphical user interface
USD768716S1 (en) 2013-12-20 2016-10-11 Deka Products Limited Partnership Display screen of a medical pump with a graphical user interface
MX2016010876A (es) 2014-02-21 2016-10-26 Deka Products Lp Bomba de jeringa que tiene un ensamble sensor de presion.
US9730731B2 (en) 2014-02-27 2017-08-15 Deka Products Limited Partnership Craniofacial external distraction apparatus
US9364394B2 (en) 2014-03-14 2016-06-14 Deka Products Limited Partnership Compounder apparatus
CN106794302B (zh) 2014-09-18 2020-03-20 德卡产品有限公司 通过将管适当加热来穿过管输注流体的装置和方法
USD792963S1 (en) 2015-02-10 2017-07-25 Deka Products Limited Partnership Bumper for a medical pump
USD805183S1 (en) 2015-02-10 2017-12-12 Deka Products Limited Partnership Medical pump
USD801519S1 (en) 2015-02-10 2017-10-31 Deka Products Limited Partnership Peristaltic medical pump
USD803387S1 (en) 2015-02-10 2017-11-21 Deka Products Limited Partnership Syringe medical pump
USD774645S1 (en) 2015-02-10 2016-12-20 Deka Products Limited Partnership Clamp
USD803386S1 (en) 2015-02-10 2017-11-21 Deka Products Limited Partnership Syringe medical pump
USD754065S1 (en) 2015-02-10 2016-04-19 Deka Products Limited Partnership AC-to-DC power supply
US10478261B2 (en) 2015-05-29 2019-11-19 Deka Products Limited Partnership System, method, and apparatus for remote patient care
CN108475534A (zh) * 2015-12-31 2018-08-31 皇家飞利浦有限公司 虚拟输液泵
USD905848S1 (en) 2016-01-28 2020-12-22 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
CN113855905B (zh) 2016-01-28 2024-01-12 德卡产品有限公司 滴注室和用于将流体输注到患者体内的设备
USD854145S1 (en) 2016-05-25 2019-07-16 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
CN106202940A (zh) * 2016-07-15 2016-12-07 浪潮电子信息产业股份有限公司 一种基于云计算的远程医疗系统
BR112019023976A2 (pt) * 2017-09-27 2020-06-09 Fresenius Vial Sas sistema e método para comunicar dados de saúde em um ambiente de cuidados de saúde
CA3095931A1 (en) 2018-04-17 2019-10-24 Deka Products Limited Partnership Peritoneal dialysis cassette with pneumatic pump
TWI680778B (zh) * 2018-06-04 2020-01-01 永磐科技股份有限公司 點滴即時監控系統及方法
JP2020005751A (ja) * 2018-07-04 2020-01-16 オリンパス株式会社 内視鏡システム
USD917045S1 (en) 2018-08-16 2021-04-20 Deka Products Limited Partnership Slide clamp
CN117838976A (zh) 2018-08-16 2024-04-09 德卡产品有限公司 滑动夹组件和用于治疗患者的系统
EP3660528A1 (en) * 2018-11-30 2020-06-03 Roche Diabetes Care GmbH Medical device with power-up routine
TWI686817B (zh) * 2019-06-05 2020-03-01 彰化基督教醫療財團法人彰化基督教醫院 藥物傳遞系統及方法
WO2020254203A1 (en) * 2019-06-19 2020-12-24 Koninklijke Philips N.V. Role-specific process compliance alert system
CA3146872A1 (en) 2019-07-16 2021-01-21 Beta Bionics, Inc. Blood glucose control system
JP2022541491A (ja) 2019-07-16 2022-09-26 ベータ バイオニクス，インコーポレイテッド 血糖制御システム
US11957876B2 (en) 2019-07-16 2024-04-16 Beta Bionics, Inc. Glucose control system with automated backup therapy protocol generation
US11839741B2 (en) 2019-07-26 2023-12-12 Deka Products Limited Partneship Apparatus for monitoring, regulating, or controlling fluid flow
USD964563S1 (en) 2019-07-26 2022-09-20 Deka Products Limited Partnership Medical flow clamp
CN110529469B (zh) * 2019-09-02 2020-12-22 深圳市绿联科技有限公司 一种夹子机构
JP2022551265A (ja) * 2019-10-04 2022-12-08 ベータ バイオニクス，インコーポレイテッド 血中グルコース制御システム
US11688501B2 (en) 2020-12-07 2023-06-27 Beta Bionics, Inc. Ambulatory medicament pump with safe access control

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2363216A (en) * 2000-03-08 2001-12-12 Ibm Publish/subscribe data processing with subscriptions based on changing business concepts
US9427520B2 (en) * 2005-02-11 2016-08-30 Carefusion 303, Inc. Management of pending medication orders
US20080177154A1 (en) * 2001-08-13 2008-07-24 Novo Nordisk A/S Portable Device and Method Of Communicating Medical Data Information
US8234128B2 (en) * 2002-04-30 2012-07-31 Baxter International, Inc. System and method for verifying medical device operational parameters
US7720910B2 (en) * 2002-07-26 2010-05-18 International Business Machines Corporation Interactive filtering electronic messages received from a publication/subscription service
WO2004107216A2 (en) * 2003-05-23 2004-12-09 Computer Associates Think, Inc. A publish/subscribe mechanism for web services
US8200775B2 (en) * 2005-02-01 2012-06-12 Newsilike Media Group, Inc Enhanced syndication
US20060270423A1 (en) * 2005-05-24 2006-11-30 Nokia Corporation Information and management service portal for subscribers of communication systems
US20070255125A1 (en) * 2006-04-28 2007-11-01 Moberg Sheldon B Monitor devices for networked fluid infusion systems
US8126731B2 (en) * 2006-10-24 2012-02-28 Medapps, Inc. Systems and methods for medical data interchange activation
JP2010510033A (ja) * 2006-11-21 2010-04-02 バクスター・インターナショナル・インコーポレイテッド 注入療法の遠隔モニタリングおよび／または管理のシステムおよび方法
CN101246486B (zh) * 2007-02-13 2012-02-01 国际商业机器公司 用于改进的表达式处理的方法和装置
US20090157695A1 (en) * 2007-08-10 2009-06-18 Smiths Medical Md Central Server for Medical Devices
JP5559810B2 (ja) * 2008-12-15 2014-07-23 コーヴェンティス，インク． 患者モニタリングシステムおよび方法
US9792660B2 (en) * 2009-05-07 2017-10-17 Cerner Innovation, Inc. Clinician to device association
US8344847B2 (en) * 2009-07-09 2013-01-01 Medtronic Minimed, Inc. Coordination of control commands in a medical device system having at least one therapy delivery device and at least one wireless controller device
CN102083243A (zh) * 2009-11-30 2011-06-01 中国移动通信集团广东有限公司 一种无线医疗网关设备、无线电子健康系统及监控方法
US20110313789A1 (en) * 2010-01-22 2011-12-22 Deka Products Limited Partnership Electronic patient monitoring system
US10453157B2 (en) * 2010-01-22 2019-10-22 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
CN102567611B (zh) * 2010-12-23 2015-05-27 中国移动通信集团江苏有限公司 一种远程医疗系统及远程医疗设备
JP2012181795A (ja) * 2011-03-03 2012-09-20 Funai Electric Co Ltd イベント管理システム及びイベント管理方法

Also Published As

Publication number Publication date
JP2020035460A (ja) 2020-03-05
WO2014100557A3 (en) 2014-10-16
SG10201705568YA (en) 2017-08-30
SG11201504861SA (en) 2015-07-30
CA3123172A1 (en) 2014-06-26
AU2018202481B2 (en) 2020-04-02
JP7057333B2 (ja) 2022-04-19
NZ709291A (en) 2018-11-30
AU2013361156A1 (en) 2015-07-16
CA2896063A1 (en) 2014-06-26
EP3567595A1 (en) 2019-11-13
CN108630308A (zh) 2018-10-09
AU2018202481A1 (en) 2018-04-26
AU2018202732B2 (en) 2019-05-23
CA2896063C (en) 2021-08-17
MX2015008049A (es) 2015-10-29
AU2013361156A8 (en) 2016-06-16
JP2016509708A (ja) 2016-03-31
JP6603433B1 (ja) 2019-11-06
AU2021209222A1 (en) 2021-08-19
BR112015014999A2 (pt) 2017-07-11
SG10201803207UA (en) 2018-05-30
JP6321676B2 (ja) 2018-05-09
CN104981808A (zh) 2015-10-14
JP6559827B2 (ja) 2019-08-14
AU2020204371A1 (en) 2020-07-23
RU2015129799A (ru) 2017-01-27
AU2021209222B2 (en) 2023-09-28
CN116403697A (zh) 2023-07-07
JP7423679B2 (ja) 2024-01-29
AU2018202732A1 (en) 2018-05-10
CN108630308B (zh) 2023-04-11
AU2023285908A1 (en) 2024-01-18
JP2019204530A (ja) 2019-11-28
EP2936363A2 (en) 2015-10-28
JP2018139117A (ja) 2018-09-06
AU2013361156B2 (en) 2019-09-19
JP2022091978A (ja) 2022-06-21
RU2015129799A3 (pt) 2018-05-10
EP2936363B1 (en) 2019-11-20
NZ747032A (en) 2020-06-26
JP2024038414A (ja) 2024-03-19
CN104981808B (zh) 2018-03-02
WO2014100557A2 (en) 2014-06-26
MX356990B (es) 2018-06-22

Similar Documents

Publication Publication Date Title
US20220044796A1 (en) System and apparatus for electronic patient care
JP7423679B2 (ja) 電子患者ケアのためのシステム
US10242159B2 (en) System and apparatus for electronic patient care
CA3190111A1 (en) Computer-implemented method, system, and apparatus for electronic patient care
AU2014302613A1 (en) System for providing aggregated patient data
JP2006520037A5 (pt)
US11342053B2 (en) Systems and methods for medical referrals via secure email and parsing of CCDs
Bogusławski Medical Expertise Ordering System-MEDEOS

Legal Events

Date Code Title Description
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B15K Others concerning applications: alteration of classification

Free format text: A CLASSIFICACAO ANTERIOR ERA: G06F 19/00

Ipc: G16H 40/20 (2018.01), G16H 40/63 (2018.01), G16H 2

B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 20/12/2013, OBSERVADAS AS CONDICOES LEGAIS.