BR112015007258A2 - sistema e método para fornecer cuidados ao paciente - Google Patents

Abstract

resumo “sistema e método para fornecer cuidados ao paciente” trata-se de um sistema para fornecer cuidados de paciente que inclui obter, consolidar, distribuir, armazenar e exibir dados médicos com o uso de plataformas de telefone celular e módulos de software e hardware não proprietários. o sistema inclui dispositivos de captação, dispositivos de obtenção, aparelhos de rede, armazenamento e computação em nuvem e dispositivos de apresentação. os dispositivos de captação são conectados aos dispositivos de obtenção por meio de conexões com fio ou sem fio. dispositivos de obtenção de captação podem ser usados nas instalações do cuidador e em um ambiente de paciente ambulatorial e podem se conectar à nuvem por meio de redes de telefone celular (3g/4g). os dados clínicos são enviados em mensagens criptografadas que têm apenas o cabeçalho codificado com o uso de uma linguagem de script-padrão, como lua. os dispositivos de apresentação incluem computadores, computadores do tipo tablet, telefones celulares e visores montados em paredes e podem estar situados em qualquer lugar, possibilitando maior acessibilidade de dados de paciente pelos cuidadores.

Description

SISTEMA E MÉTODO PARA FORNECER CUIDADOS AO PACIENTE

CAMPO [001] O presente relatório descritivo refere-se a sistemas médicos. Mais particularmente, o presente relatório descritivo se refere a um sistema e método de monitoramento de paciente distribuído para fornecer cuidados de paciente que habilite redes de telefone celular, serviços com base em nuvem, dispositivos eletrônicos de consumidor e conectividade a redes-padrão existentes para adquirir, consolidar, analisar, distribuir, armazenar e exibir dados médicos.

ANTECEDENTES [002] Sistemas-padrão para fornecer cuidados de paciente empregados, em geral, em ambientes de hospital incluem módulos para adquirir, consolidar, distribuir, armazenar e exibir dados médicos de paciente. Tais módulos compreendem vários componentes de hardware que executam inúmeros programas de software, geralmente conectados a uma rede de informações. Os sistemas atualmente disponíveis para fornecer cuidados de paciente utilizam hardware proprietário, limitando, dessa forma, opções para expansão e restringindo o uso dos sistemas. Na maioria dos casos, os sistemas permitem somente software de aplicação especifica que foi projetado de acordo com as exigências de execução do sistema. Além disso, devido a atualizações periódicas, ambientes de hospital frequentemente têm múltiplas versões tanto de hardware quanto de software em operação em seus sistemas. Logo, esses sistemas tendem a ser como caixas fechadas que podem ser personalizadas somente até certo ponto. À medida que a tecnologia avança, os hospitais

2/72 encontram dificuldades crescentes que integram nova funcionalidade com sistemas existentes. Tipicamente, se exige que uma equipe de tecnologia de informações no local (IT) realize solução de problemas e atualizações manuais.

[003] Os sistemas atuais para fornecer cuidados de paciente incluem redes que utilizam protocolos de comunicação tradicionais que precisam definir estritamente o formato, os esquemas e a codificação das mensagens que compreendem o protocolo. Essas definições formam um contrato entre um transmissor de informações e um receptor de informações no sistema e estão tipicamente na forma ou de codificações rigorosas em nível de bit ou codificações de nível mais alto, tal como Linguagem de Marcação Extensível (XML). A codificação em nível de bit envolve um gabarito preciso de cada bit e byte de cada mensagem no nível binário e, logo, define rigorosamente o conteúdo e o formato exato de todas as mensagens no protocolo. O protocolo TCP/IP utilizado na internet é um exemplo da codificação em nível de bit. A codificação em XML utiliza um esquema específico para protocolo para colocar em camadas as regras necessárias no topo de um formato padronizado (XML) para definir o gabarito de mensagens. O padrão de página da web de linguagem de marcação de hipertexto (HTML) é um exemplo de codificação em XML.

[004] Ambos os tipos de codificação exigem que o transmissor e o receptor concordam sobre o mesmo protocolo. Um receptor que espera dados em XML seria incapaz de processar dados binários provenientes de um transmissor e vice versa. Portanto, mudanças e aprimoramentos ao protocolo precisam ser feitas em passo a passo, em que o

3/72 transmissor e o receptor são atualizados simultaneamente. Os sistemas atuais são frequentemente implantados amplamente, tornando tais atualizações simultâneas pouco práticas e resultando em protocolos que se tornam travados com pouca evolução.

[005] Além disso, a transmissão de informações por meio de protocolo-padrão envolve várias etapas de conversão. O transmissor precisa codificar dados antes de enviar os mesmos e o receptor precisa decodificar os dados para recuperar os mesmos. A codificação e a decodificação continuas de dados podem ser complexas e podem aumentar significativamente a carga. Fazer mudanças ao protocolo subjacente tipicamente exige um novo trabalho dos estágios tanto de codificação quanto de decodificação, levando, também, a custos aumentados.

[006] Os protocolos de comunicação em redes típicas vêm em dois tipos básicos: orientado por conexão e sem conexão. Os protocolos orientados por conexão exigem um procedimento de aperto de mãos entre as duas partes em comunicação antes da troca de dados poder ocorrer, enquanto os protocolos sem conexão permitem a troca de dados sem uma instalação ou um aperto de mãos precedentes.

[007] A proteção das comunicações é tipicamente realizada com criptografia, e todas as formas extintas de criptografia exigem que as partes em comunicação tenham segredos compartilhados, tipicamente sob a forma de chaves, que permitem que as mesmas criptografem e desencriptem mensagens. Embora haja muitos conjuntos de procedimentos para compartilhamento de chaves, todos envolvem o uso de um protocolo orientado por conexão de modo que as chaves

4/72 possam ser trocadas durante a instalação da conexão. Além disso, cada conexão individual precisa especificar um conjunto único de segredos. Logo, se um primeiro agente está se comunicando com 100 outros agentes, cada conversa individual envolve uma conexão criptografada individual, exigindo que o primeiro agente gerencie 100 conexões simultâneas e chaves associadas. Como tal, em sistemas em que muitos agentes conversam com muitos outros, o número total de conexões aumenta exponencialmente. Isso aumentará os custos e tornará o sistema mais lento.

[008] Para superar isso, muitos sistemas utilizam uma única troca central que roteia comunicações entre agentes. O número total de conexões é, então, igual ao número de agentes visto que cada agente tem que conectar somente com a troca central compartilhada. No entanto, a não ser que a troca seja confiada, os agentes ainda precisam manter pares de chave de criptografia individuais para cada par de agentes de comunicação. Logo, os agentes ainda precisam conectar a troca de chaves.

[009] As mensagens enviadas entre os transmissores e os receptores irão variar em importância e prioridade do trivial para o critico. Visto que é, em geral, extremamente difícil ou impossível garantir a entrega de uma dada mensagem, é frequentemente útil para o receptor de uma mensagem reconhecer o recebimento do remetente dos dados. Visto que essa geração de recebimento consume a largura de banda de rede (pelo menos uma nova new mensagem é gerada pelo receptor para cada mensagem recebida), a mesma é frequentemente reservada para mensagens da mais alta importância.

5/72 [010] Assim como com codificação de mensagem, os protocolos de comunicação tradicionais formam um contrato entre transmissores e receptores e precisam contar com regras estritamente definidas para a especificação que os receptores geram e enviar um recebimento de entregue. Tipicamente, o protocolo irá especificar um campo ou uma frequência de campos que precisam ser decodificados para determinar se uma mensagem de recebimento deve ser gerada. Campos adicionais definem o formato da mensagem de recebimento e o endereço de rede do remetente. A fim de um sistema de rede tradicional garantir geração de recebimento de modo eficaz, todos os agentes na rede precisam estar executando versões compatíveis do protocolo de modo que solicitações de recebimento de mensagens, descrições de formato e designações de endereço estejam todos em formatos compatíveis.

[011] Além disso, a geração de recebimento de mensagem tradicional é bem restritiva em que o formato do recebimento de retorno é determinado pela funcionalidade codificada nas pilas de software de receptores. Se uma sequência complexa de ações for desejada mediante recebimento de uma classe particular de mensagens, a mesma precisa ser codificada na pilha de software de cada agente de rede.

[012] Por exemplo, uma classe de mensagens críticas exige que não só um recebimento-padrão seja gerado (uma mensagem retornada ao remetente), porém também que uma notificação de recebimento de mensagem secundária seja enviada a servidor de registro de dados (que acompanha todos os recebimentos de mensagem de prioridade alta). Em

6/72 um sistema tradicional, esse comportamento terra que ser compilado no protocolo de mensagem de modo que campos de dados opcionais adicionais (habilitação de notificação de recebimento secundária, endereço de servidor de notificação secundária, comportamento especificado se um servidor secundário não estiver disponível, etc.) fossem utilizados para implantação. Essa é uma resposta complexa mediante recebimento de mensagem que é dificil de codificar em um protocolo tradicional. 0 efeito é crescer o tamanho de todas as mensagens e tornar o protocolo progressivamente mais complexo, mais lento e dificil de utilizar e manter.

[013] Com cada novo comportamento que é codificado no protocolo dessa maneira, as pilhas de software de rede em todos os agentes de rede crescem em complexidade e consumo de memória e se tornem menos eficientes. Além disso, tal um recurso não pode ser utilizado até que todos os agentes de rede estejam executando uma versão compatível do protocolo que suporta o recurso.

[014] Durante o envio de mensagens, redes tipicas também contam cum uma variedade de protocolos para determinar a rota ideal para pacotes de dados. Esses protocolos determinam a trajetória ideal entre pontos de extremidade com uso de métricas de custo estáticas. A maioria é baseada no algoritmo de Dijkstra, um algoritmo de busca de gráfico que soluciona o problema de trajetória

mais curta	de	fonte única	para um gráfico	com	custos	de
trajetória	de	margem	não	negativos, para	determinar	a
trajetória	mais	curta	entre	dois vértices.	Cada	enlace	é

atribuído um custo baseado em um atributo especifico, que é geralmente a largura de banda disponível.

7/72 [015] O protocolo de roteamento Primeira Trajetória Mais Curta Aberta (OSPF) é um exemplo comum de um protocolo de determinação de rota. Embora outros atributos estejam disponíveis, a OSPF é comumente configurada para atribuir a cada link de rede disponível um custo de 10^A8/largura de banda. Um link de 100 Mbit/s de largura de banda terra um custo de 1 e um link de 10 Mbit/s terra um custo de 10. Na seleção de uma trajetória entre duas redes, a OSPF escolheria a trajetória com o custo mais baixo.

[016] O Protocolo de Estrutura Estendida (STP), um protocolo de camada de link, também seleciona trajetórias ideais para uma rede com base em largura de banda de interface disponível com uso de uma tabela de custo-padrão. Para STP, 10 Mbit/s é dado um custo de 100, embora 100 Mbit/s seja dado um custo de 19. A soma de todos os links em cada trajetória é utilizada para determinar o custo de

trajetória,	com a	trajetória	de custo	mais	baixo	escolhida
para comunicações	naquela rede.
[017] Nesses	protocolos,	o cust	o de	trajetória	é
determinado	de acordo com a	velocidade de	link	negociada
para cada	interface. No	entanto,	a	velocidade	de
transmissão	real	pode ser	impactada	em	tempo	real	por
congestionamento	de rede, f	>erda de	pacote e	atraso	de

enfileiramento. Essas propriedades mudam dinamicamente e não são consideradas quando a trajetória ideal é computada com uso de métricas de custo estáticas.

[018] Redes tipicas utilizam vários protocolos para transferir dados de um ou muitos transmissores para muitos outros receptores. A transferência de dados de um ou muitos remetentes simultaneamente para múltiplos recipientes é

8/72 chamada de difusão seletiva. A difusão seletiva independente de protocolo (PIM) é um grupo de protocolos que não incluem seu próprio mecanismo de descoberta de topologia porém utilizam informações de roteamento fornecidas por outros protocolos. 0 protocolo de gerenciamento de grupo internet (IGMP) é utilizado por hospedeiros e roteadores em redes para estabelecer associações de grupo de difusão seletiva. Durante a operação de uma rede típica que utiliza IGMP, um dispositivo precisa sincronizar estado novamente, ou reestabelecer conexão, com um hospedeiro ou roteador sempre que o dispositivo estiver em roaming. Manter o estado ao longo de roteadores durante roaming exige que o sistema retenha informações de sessão ou situação de dispositivos durante múltiplas solicitações. Isso torna o sistema mais lento e aumenta a necessidade de armazenamento de memória adicional.

[019] Muitos dos transmissores e dos receptores que transferem mensagens em redes típicas são dispositivos móveis. Esses dispositivos frequentemente têm um orçamento de potência limitado para a transmissão de dados. Os mesmos são alimentados, em geral, por baterias e não é incomum que a transmissão por rádio (bluetooth, 802.11 sem fio, 3G, 4G, LTE, etc.) utilizar uma grande porcentagem da potência disponível e da energia total na batería. Esse problema é particularmente agudo se o dispositivo estiver enviado dados continuamente conforme pode ser visto em dispositivos móveis utilizados como parte de um sistema de monitoramento médico.

[020] Outro problema encontrado durante a difusão

9/72 seletiva em redes móveis ocorre quando mensagens duplicadas são enviadas por um transmissor. Durante o envio de mensagens com uso de transmissão de radiofrequência (RF) conforme descrito acima, os sistemas são limitados na quantidade de dados que podem transferir pela quantidade de largura de banda disponível e a potência de bateria dos dispositivos móveis. Exigir mais largura de banda para interconexões de RF é associado a um aumento em custo geral do sistema. 0 envio de mensagem duplicada não só consume mais largura de banda porém também resulta em drenagem de bateria desnecessária em dispositivos móveis.

[021] Durante o alarme, os sistemas tradicionais para fornecer cuidados de paciente são tipicamente configurados para anunciar alarmes primeiramente no dispositivo conectado ao paciente. Os alarmes que são gerados pelo dispositivo conectado ao paciente são frequentemente replicados e exibidos em dispositivos fisicos remotos tal como em uma estação de trabalho central. Uma estação de trabalho central é um visor grade tipicamente utilizado por um único cuidador para observar a situação de múltiplos pacientes. Além disso, dispositivos de alarme móveis podem ser desgastados por cuidadores conforme os mesmos se movem pela unidade de tratamento. Esses dispositivos têm a capacidade de notificar o cuidador se um dos pacientes tiver um evento de alarme.

[022]

Essas abordagens de alarme todas fornecem uma resposta programada para uma condição de alarme que tipicamente segue a trajetória de: 1) soar alarme no dispositivo conectado ao paciente; 2) soar alarme no visor central ou remoto; 3) notificar o cuidador do alarme; e, 4)

10/72 se o cuidador não responder, então notificar outro cuidador com base na escalação predefinida até que um cuidador responda. Embora eficaz, esquemas de alarme tradicionais não levam em consideração a localização fisica do paciente ou do cuidador mais próximo, o que pode levar a atrasos em resposta de alarme.

[023] A fadiga de alarme é outro problema encontrado por cuidadores que utilizam sistemas de cuidados de paciente tradicionais. Quando um monitor de paciente detecta uma condição para a qual o mesmo deve criar um alarme, o mesmo criará notificações para o cuidador, tais como, um tom em repetição audivel alto, um indicador que pisca no dispositivo ou no visor, uma mensagem de texto que descreve o alarme, etc. Depois que um cuidador responde a inúmeros alarmes para muitos pacientes diferentes durante um turno, o cuidador pode se tornar dessensibilizado a tons de alarme. Isso pode levar a prejuizo ao paciente se alarmes importantes forem ignorados ou desativados inapropriadamente pelo cuidador. Os sistemas de monitoramento de paciente existentes tentam minimizar fadiga de alarme permitindo-se que cuidadores silenciem alarmes durante certas situações. O silenciamento de um alarme não desliga o alarme, ao invés, porém, desliga tipicamente os tons de alarme de áudio por um periodo de tempo para que o cuidador não se distraia ao mesmo tempo que trata o paciente.

[024] Silêncio de alarme é uma forma de silenciar que desliga alarmes de áudio por um periodo de tempo. O reconhecimento de alarme (alarme continuo) reduz a intensidade da notificação de alarme durante a duração da

11/72 situação de alarme. Se em qualquer momento a condição de alarme desaparece, o estado de reconhecimento de alarme é liberado e um novo alarme do mesmo tipo faria com que o comportamento de alarme total ocorra novamente. Por exemplo, para uma condição de alarme tal como fibrilação atrial (que tipicamente não é uma ameaça de vida e pode continuar por períodos de tempo estendidos), o comportamento de reconhecimento de alarme pode ser para encerrar os alarmes que pisca e encerrar os alarmes audíveis porém ainda indica que o alarme está ocorrendo na zona de parâmetro junto com um ícone que indica que o cuidador reconheceu a condição de alarme. Esse estado persistiría até que o alarme fosse reiniciado ou até que a condição fosse resolvida. Se o paciente saísse da fibrilação atrial por pelo menos um período de tempo especificado mínimo e então entrasse novamente, o alarme total apropriado para fibrilação atrial começaria novamente.

[025] O reconhecimento de alarme (alarme travado) é para situações de alarme suficientemente importantes que, se as mesmas ocorrerem, então um cuidador precisa ser informado. Se um alarme travado ocorrer, então o monitor de paciente continuará a soar o alarme mesmo após a condição de alarme não estiver mais presente até que um cuidador reconheça que o alarme tenha sido observado. Uma vez reconhecido, o alarme irá desligar se a condição não estiver mais presente. Embora esses esquemas de silenciamento de alarme sejam eficazes, os mesmos podem ser aprimorados para serem melhor distribuídos e orientados para uma abordagem de time de cuidadores.

12/72 [026] Além disso, sistemas atuais são geralmente fixos e não podem ser utilizados para fornecer cuidados de paciente, uma vez que um paciente tenha sido retirado de um ambiente de hospital. Tais sistemas não fornecem um método para pacientes e seus cuidadores se conectarem a médicos e profissionais da saúde uma vez que um paciente tenha recebido alta porém ainda necessitem de atenção médica.

[027] Portanto, o que é exigido é um sistema flexivel e robusto para fornecer cuidados de paciente que não seja limitado ao uso de tecnologia proprietária. O novo sistema deve ser flexivel o suficiente para fornecer suporte por vários anos sem a necessidade de substituir os módulos de base. O sistema também deve exigir pouco conhecimento técnico no local. Tal sistema operaria com uso de principio de software-como-um-serviço (SaaS), em que cuidadores, pacientes e familias acessam programas e dados armazenados em uma nuvem. A nuvem fornece as exigências de armazenamento e computação do sistema, deslocando o uso para longo de clientes gordos em que programas e dados são armazenados localmente. A computação em nuvem diminuirá custos e aumentará a flexibilidade do sistema.

[028] Também é necessário um sistema em que a codificação de mensagem é administrada de uma maneira mais eficaz em termos de custo e mais eficiente. Especificamente, o que é necessário é um protocolo de codificação flexivel que simplifique aquelas etapas de codificação e decodificação e permita aprimoramentos ao sistema sem exigir atualizações simultâneas de componentes de sistema. Tal protocolo de codificação também simplificaria a inclusão de programas executáveis na

13/72 transmissão de mensagem, tal como, programas de recebimento de entrega.

[02 9] Além disso, há uma necessidade de uma troca sem conexão para enviar mensagens criptografadas entre duas partes sem exigir que essas partes negociem chaves ou outros segredos antes da troca da mensagem. O que é necessário é uma troca confiada central para a transmissão de sem conexão de mensagens ao longo da rede.

[030] O que também é necessário é um protocolo de roteamento de mensagens que irá considerar uso de rede em tempo real, tal como congestionamento, perda de pacote e atraso de enfileiramento, durante a determinação da rota mais rápida.

[031] Também é necessário um sistema com a capacidade de difusão seletiva eficiente em que dispositivos podem entrar em roaming sem a necessidade de sincronizar novamente com roteadores, mantendo a operação de roteador sem estado. Tal sistema reduziria o consumo de bateria nos dispositivos e diminuir as demandas na rede. Além disso, um sistema é necessário que minimize o consumo de bateria de dispositivo móvel e largura de banda reduzindo-se a incidência de envio de mensagem duplicada.

[032] O que também é necessário é um método de controle do fluxo de mensagens em uma rede para minimizar o consumo de potência no transmissor. Os dispositivos sem fio são, em geral, mais eficientes quando transmitem um único bloco de dados de um certo número de bytes que se os mesmos bytes forem transmitidos como múltiplos blocos menores de dados. Portanto, o que é necessário é um método de envio de múltiplas mensagens juntamente em um único bloco ao invés

14/72 de múltiplas mensagens menores.

[033] Há uma necessidade de roteamento de prioridade de alarme baseado nas informações de localização e presença tanto do paciente quanto dos cuidadores. É necessário, também, é um método para silenciamento de alarme que considera um time distribuído de cuidadores.

[034] Há, também, uma necessidade de um sistema em que módulos de hardware individuais são suficientemente pequenos e móveis para permitir a transferência ao longo de departamentos de hospital e para serem enviados para casa com pacientes por um tempo limitado após a alta.

[035] Há uma necessidade de um sistema em que módulos de hardware individuais são configuráveis para fazer interface com tipo diferente de sensores de paciente para fornecer cuidado apropriado para o paciente do ambiente de hospital ao cenário do paciente ambulatorial.

[036] O que também é necessário é um sistema que forneça vigilância de paciente ubiqua permitindo-se que pacientes, suas familias e cuidadores conectem de uma maneira segura e confiável. Há, também, uma necessidade de um sistema para fornecer cuidados de paciente que suporte o uso de soluções de terceiros, adaptando-se o sistema para receber dados fisiológicos do paciente de dispositivos de terceiros e outras informações geradas a partir da análise de dados, encorajando, dessa forma, inovação.

SUMÁRIO [037] O presente relatório descritivo é direcionado para um sistema para fornecer cuidados de paciente que compreende: um primeiro dispositivo de computação que tem um primeiro meio legivel por computador volátil ou não

15/72 volátil, que não inclui meios para transmissão para transmitir ondas, em que o dito primeiro meio compreende: uma primeira pluralidade de instruções programáticas, em que, quando executada pelo dito primeiro dispositivo de computação, a dita primeira pluralidade de instruções programáticas: criptografa, com uso de uma linguagem de script-padrão, um programa executável e fixa o dito programa criptografado ao cabeçalho de uma mensagem; e transmite a dita mensagem do primeiro dispositivo de computação para um segundo dispositivo de computação por meio de uma conexão sem fio; um segundo dispositivo de computação que tem um segundo meio legível por computador volátil ou não volátil, que não inclui meios para transmissão para transmitir ondas, em que o dito segundo meio compreende: uma segunda pluralidade de instruções programáticas, em que, quando executada pelo segundo dispositivo de computação, a dita segunda pluralidade de instruções programáticas: recebe a dita mensagem do dito primeiro dispositivo de computação; determina, da dita mensagem, pelo menos um dispositivo de computação-alvo destinado a receber a dita mensagem; e, transmitir a dita mensagem do dito segundo dispositivo de computação para o dito pelo menos um dispositivo de computação-alvo por meio de uma conexão sem fio; e, pelo menos um dispositivo de computação-alvo que tem um terceiro meio legível por computador volátil ou não volátil, que não inclui meios para transmissão para transmitir ondas, em que o dito terceiro meio compreende: uma terceira pluralidade de instruções programáticas, em que, quando executada pelo terceiro dispositivo de computação, a dita terceira

16/72 pluralidade de instruções programáticas: recebe a dita mensagem do dito segundo dispositivo de computação; desencriptografa o dito programa executável; e, executa o dito programa executável e recebe, dessa forma a dita mensagem; em que o dito segundo dispositivo de computação é um dispositivo de computação baseado em nuvem.

[038] O presente relatório descritivo também é direcionado para um sistema para fornecer cuidados de paciente que compreende: pelo menos um dispositivo de captação configurado para detectar e relatar pelo menos um parâmetro fisiológico de um paciente; pelo menos um dispositivo de obtenção acoplado ao dito pelo menos um dispositivo de captação em que o dito dispositivo de obtenção recebe dados de paciente eletrônicos do dito pelo menos um dispositivo de captação e inclui memória com a capacidade de armazenar os ditos dados de paciente; pelo menos um aparelho de rede acoplado ao dito pelo menos um dispositivo de obtenção em que o dito aparelho de rede é configurado para receber os ditos dados de paciente do dito dispositivo de obtenção; uma rede para fornecer computação em nuvem em que o dito pelo menos um aparelho de rede é acoplado a dita rede e em que a dita rede inclui um banco de dados para armazenar os ditos dados de paciente de modo que os ditos dados de paciente sejam acessíveis ao longo de todos os dispositivos de rede; e, pelo menos um dispositivo de apresentação acoplado à dita rede em que o dito dispositivo de apresentação é configurado para acessar os ditos dados de paciente e exibir os ditos dados de paciente em uma interface de usuário gráfica, em que a transmissão dos ditos dados de paciente eletrônicos ao longo da dita

17/72 rede inclui criptografar os ditos dados de paciente

codificando-se um	programa	executável com	uso	de	uma
linguagem de	script	-padrão e	fixando o dito programa a	uma
mensagem que	inclui	os ditos	dados de paciente	•
[03 9] Em	uma	modalidade, o aparelho	de	rede	é

localizado próximo ao paciente. Em outra modalidade, o aparelho de rede é localizado distante do paciente.

[040] Em uma modalidade, o dispositivo de captação é acoplado ao dito pelo menos um dispositivo de obtenção por meio de uma conexão com fio. Em outra modalidade, o

dispositivo	de	captação é	acoplado	ao dito	pelo	menos	um
dispositivo	de	obtenção por	meio de	uma conexão sem fio.
[041] Em	uma modalidade, tanto	o dito	pelo	menos	um
dispositivo	de	captação	quanto o	dito	pelo	menos	um

dispositivo de obtenção podem se conectar à rede por meio de uma conexão 3G/4G.

[042] Em uma modalidade, a linguagem de script-padrão é Lua.

[043] Em uma modalidade, o dispositivo de apresentação compreende qualquer um dentre de um PC tradicional, computador do tipo tablet, telefone inteligente ou visor montado em parede.

[044] Em uma modalidade, o dispositivo de obtenção também funciona como um dispositivo de apresentação.

[045] Em uma modalidade, o dispositivo de obtenção duplica e armazena todos os dados clínicos para o dito paciente na dita memória e funciona como um monitor independente no evento de falha sistema.

[046] Em uma modalidade, o dispositivo de obtenção é um dispositivo fixo em uma instalação de cuidador. Em outra

18/72 modalidade, o dispositivo de obtenção é um dispositivo móvel que permanece com o dito paciente mediante alta e para cuidados de paciente ambulatorial.

[047] Em uma modalidade, o sistema para fornecer cuidados de paciente inclui adicionalmente um algoritmo de roteamento à base de custo que calcula a rota de mensagem mais eficiente medindo-se diretamente o desempenho de rede atual durante o uso real.

[048] Em uma modalidade, o sistema para fornecer cuidados de paciente inclui adicionalmente um protocolo de roteamento de alarme que roteia a prioridade de alarme baseado nas informações de localização e presença tanto do dito paciente quanto de um cuidador. Em uma modalidade, um cuidador pode silenciar ou reduzir em volume um alarme

audível	para	todos	os dispositivos atribuídos	ao dito
paciente.
[049]	Em	uma modalidade,	o sistema para	fornecer
cuidados	de	paciente	inclui	adicionalmente uma	troca de
mensagem	confiada	central	que estabelece	um link

criptografado uma vez por dispositivo entre a toca e cada transmissor e receptor de mensagem. Em uma modalidade, a troca de mensagem central acumula mensagens não urgentes para serem enviadas periodicamente. Em uma modalidade, o transmissor de mensagem é configurado para enviar cada mensagem somente uma vez e a dita troca de mensagem central é configurada para duplicar e enviar cada mensagem para múltiplos recipientes com base em uma lista de assinatura incluída em um cabeçalho da dita mensagem.

[050] O presente relatório descritivo também é direcionado para um método para fornecer cuidados de

19/72 paciente que compreende as seguintes etapas: fornecer um sistema de cuidados de paciente que compreende: pelo menos um dispositivo de captação configurado para detectar e relatar pelo menos um parâmetro fisiológico de um paciente; pelo menos um dispositivo de obtenção acoplado ao dito pelo menos um dispositivo de captação em que o dito dispositivo de obtenção recebe dados de paciente eletrônicos do dito pelo menos um dispositivo de captação e inclui memória com a capacidade de armazenar os ditos dados de paciente; pelo menos um aparelho de rede acoplado ao dito pelo menos um dispositivo de obtenção em que o dito aparelho de rede é configurado para receber os ditos dados de paciente do dito dispositivo de obtenção; uma rede para fornecer computação em nuvem em que o dito pelo menos um aparelho de rede é acoplado à dita rede e em que a dita rede inclui um banco de dados para armazenar os ditos dados de paciente de modo que os ditos dados de paciente é acessível ao longo de todos os dispositivos de rede; e, pelo menos um dispositivo de apresentação acoplado à dita rede em que o dito dispositivo de apresentação é configurado para acessar os ditos dados de paciente e exibir os ditos dados de paciente em uma interface de usuário gráfica, detectando e relatando o dito pelo menos um aparelho paciente parâmetro fisiológico com uso do dito pelo menos um dispositivo de captação; transmitir dados eletrônicos representativos do dito pelo menos um aparelho parâmetro fisiológico para o dito dispositivo de obtenção; criptografar os ditos dados de paciente codificando-se codificação um programa executável com uso de uma linguagem de script-padrão e fixando-se o dito programa a uma mensagem que inclui os

20/72 ditos dados de paciente; transmitir os ditos dados criptografados para o dito aparelho de rede; armazenar os ditos dados na dita rede com uso de computação em nuvem; acessar, descriptografar e exibir os ditos dados com uso do dito dispositivo de apresentação.

[051] As modalidades mencionadas anteriormente e outras modalidades do presente relatório descritivo serão descritas em mais profundidade nos desenhos e na descrição detalhada fornecida abaixo.

BREVE DESCRIÇÃO DOS DESENHOS [052] Esses e outros recursos e vantagens da presente invenção serão verificados adicionalmente, à medida que estiverem mais bem entendidos por referência à descrição detalhada quando considerada em combinação com os desenhos anexos, em que:

a Figura IA é um diagrama que ilustra uma modalidade do fluxo de trabalho do sistema de informação de dados médicos do presente relatório descritivo;

a Figura 1B ilustra uma	situação	de	uso
exemplificativa da presente invenção	em uma	unidade	de
tratamento intensivo (CTI) de um hospital;
a Figura 1C ilustra uma	situação	de	uso
exemplificativa do sistema do presente	relatório	descritivo

em uma enfermaria geral de um hospital;

a Figura	1D ilustra uma	situação	de uso
exemplificativa do	sistema do presente	relatório	descritivo

em uma situação domiciliar;

a Figura 2 é um diagrama de blocos que ilustram uma topografia fisica exemplificativa de uma modalidade do sistema de informação de dados médicos do presente

21/72 relatório descritivo;

a Figura 3 é um diagrama de blocos que ilustra a arquitetura de software de uma modalidade do aplicativo de portal de sistema;

a Figura 4 é um fluxograma que ilustra as etapas envolvidas na inicialização de um dispositivo de obtenção no sistema de informação de dados médicos do presente relatório descritivo;

a Figura 5 é um fluxograma que ilustra uma modalidade das etapas envolvidas em uma troca de mensagens exemplificativa entre dois aplicativos; e, a Figura 6 é um fluxograma que ilustra uma modalidade do fluxo de mensagens a partir de um par de aplicativos no sistema de informação de dados médicos do presente relatório descritivo.

DESCRIÇÃO DETALHADA [053] O presente relatório descritivo é direcionado a um sistema para fornecer cuidados ao paciente mediante a obtenção, a consolidação, a distribuição, o armazenamento e exibição de dados médicos com o uso de plataformas de celular e de módulos de hardware e de software não proprietários. Em uma modalidade, os sistemas do presente relatório descritivo são implantados com o uso seguinte: dois ou mais computadores ou dispositivos de computação, em que os computadores ou os dispositivos de computação executam pelo menos uma pluralidade de instruções programáticas; um meio para transferir dados entre os ditos dispositivos de computação; e, pelo menos um protocolo projetado para facilitar a transferência de dados entre os ditos dispositivos de computação.

22/72 [054] Além disso, uma pessoa de habilidade comum na técnica observaria que os recursos descritos no presente pedido podem operar em qualquer plataforma de computação incluindo, porém sem limitação: um computador do tipo laptop ou computador do tipo tablet; computador pessoal; assistente pessoal digital; celular; servidor; processador integrado; chip processador de sinal digital (DSP) ou um dispositivo de imageamento especializado com capacidade para executar as instruções ou código programático.

[055] Deve-se observar adicionalmente que a plataforma fornece as funções descritas no presente pedido executandose uma pluralidade de instruções programáticas, que são armazenadas em uma ou mais memórias não voláteis, com o uso de um ou mais processadores e apresenta e/ou recebe dados através dos transceptores em comunicação de dados com uma ou mais redes cabeadas ou sem fio.

[056] Deve-se observar adicionalmente que cada dispositivo tem receptores sem fio e/ou com fio e transmissores com capacidade para enviar e transmitir dados, pelo menos um processador com capacidade para processar as instruções programáticas, memória com capacidade para armazenar as instruções programáticas, e um software constituído de uma pluralidade de instruções programáticas para realizar os processos descritos no presente documento. Além disso, o código programático pode ser compilado (tanto pré-compilado como compilado no momento exato) em um único aplicativo que é executado em um único computador, ou distribuído entre diversos computadores diferentes que operam localmente ou remotamente entre si.

23/72 [057] O sistema do presente relatório descritivo fornece um ou mais dispositivos de captação que coletam dados psicológicos do paciente e transmitem os dados captados para um dispositivo de obtenção que, em seguida, envida os dados à nuvem, interconectando os componentes do sistema. A nuvem consolida os dados e, então, distribui os dados para um ou mais dispositivos de exibição ou de apresentação.

[058] O sistema possibilita que terceiros inovem e desenvolvam aplicativos, potencializando, desse modo, novas tecnologias rapidamente. Além disso, o presente sistema é fácil de instalar, de selecionar problemas e presta serviço e não exige hardware especial, rede de comunicação, ou equipe de TI. Além disso, o sistema tem capacidade para funcionar em uma a infraestrutura de rede não robusta e tem a capacidade para operar em um modo seguro contra retrocesso. Ainda adicionalmente, o sistema para fornecer cuidados ao paciente compreende um módulo de monitoramento de paciente que pode ser fixado ao paciente e pode ser levado com o paciente mediante a alta de um hospital e para cuidados ao paciente ambulatorial.

[059] Em uma modalidade, o sistema usa um protocolo de comunicações em que durante o envio de uma mensagem, um transmissor inclui um pequeno programa de computador escrito em uma linguagem de script-padrão industrial. Quando um receptor recebe a mensagem, o mesmo executa o programa, tornando os dados de mensagem em uma forma utilizável. Isso elimina a necessidade de codificar rigorosamente a mensagem em si e fornece uma flexibilidade consideravelmente intensificada em uma codificação de

24/72 mensagem. Em uma modalidade, a linguagem de script é Lua. Em uma modalidade, um transmissor tem capacidade para criar adicionalmente a sua própria confirmação de retorno inserindo-se um código de confirmação de entrega executável no programa incluído. 0 receptor irá executar o código e enviar a confirmação de entrega mediante o recebimento da mensagem original.

[060] Em uma modalidade, o sistema inclui uma troca de mensagens que usa um algoritmo de roteamento com base em custo que calcula a rota de mensagem mais eficiente com o uso de múltiplos fatores incluindo a medição direta do desempenho de rede atual durante o uso real.

[061] Em uma modalidade, o sistema fornece a troca sem conexão de mensagens criptografadas eliminando a necessidade de transmissores e receptores para negociar chaves ou outros segredos anteriores à transferência de mensagem. Isso é realizado fornecendo-se uma troca de mensagens central de confiança que estabelece um link criptografado uma vez por dispositivo entre a troca e cada transmissor e receptor.

[062] Em uma modalidade, o sistema fornece um mecanismo para acumular mensagens não urgentes a serem enviadas periodicamente em vez de continuamente, desse modo, conservando potência de batería de dispositivo móvel e uso de largura de banda. Além disso, o sistema dita que as mensagens destinadas para múltiplos recipientes sejam enviadas apenas uma vez por um transmissor. Cada mensagem inclui dentro de seu cabeçalho uma lista de assinatura completa com todos os recipientes. O roteador de sistema duplica, então, a mensagem e enviar a mesma e cada

25/72 recipiente. Isso também ajuda a reduzir o consumo de bateria e o uso de largura de banda geral.

[063] Em uma modalidade, o sistema roteia a prioridade de alarme com base nas informações de localização e de presença tanto do paciente quanto do cuidador. Os alarmes são sondados tanto na localização do responsável cuidador e na localização de pelo menos um cuidador mais próximo ao paciente, ou um cuidador designado para fornecer os melhores cuidados com base no tipo especifico de alarme.

[064] Em uma modalidade, o sistema permite que os cuidadores para suprimir um alarme que resulta em alarmes audiveis que são silenciados ou reduzidos em volume para todos os dispositivos atribuídos a um paciente particular.

[065] A presente invenção é direcionada a múltiplas modalidades. A revelação a seguir é fornecida a fim de possibilitar que uma pessoa que tem habilidade comum na técnica coloque em prática a invenção. A linguagem, usada neste relatório descritivo não deve ser interpretada como uma negação geral de qualquer modalidade especifica ou usada para limitar as reivindicações além do significado dos termos usados nas mesmas. Os princípios gerais definidos no presente documento podem ser aplicados a outras modalidades e aplicações sem se afastar do espirito e do escopo da invenção. Além disso, a terminologia e a fraseologia usadas têm o propósito de descrever modalidades exemplificativas e não devem ser limitantes. Portanto, a presente invenção deve estar em conformidade com o escopo mais amplo que abrange inúmeras alternativas, modificações e equivalentes consistentes nos princípios e recursos revelados. Com o propósito de esclarecimento, os detalhes

26/72 em relação ao material técnico que é conhecido nos campos técnicos em relação à invenção não foram descritos detalhadamente de modo a não obscurecer necessariamente a presente invenção.

VISÃO GERAL DO SISTEMA [066] A Figura IA é um diagrama que ilustra uma modalidade do fluxo de trabalho 100 do sistema de informação de dados médicos do presente relatório descritivo. A etapa 102 representa a obtenção de dados médicos por meio de dispositivos de captação 113 que, em várias modalidades, incluem sensores em circulação (COTS) comerciais, dispositivos herdados (para entrada apenas), e dispositivos de terceiros. Em várias modalidades, o sistema compreende uma pluralidade de aplicativos ligue e use disponibilizadas por um ou mais fornecedores de aplicativos. O sistema inclui pelo menos um dispositivo de captação 113, pelo menos um dispositivo de obtenção 112, um aparelho de rede de GHC/nuvem 114 e dispositivos de apresentação/exibição 116. Em uma modalidade, o pelo menos um dispositivo de captação 113 pode ser conectado ao pelo menos um dispositivo de obtenção 112 por meio de conexões cabeadas ou sem fio. Os dispositivos de captação 113 podem ser usados com um dispositivo de obtenção 112 em um ambiente de paciente ambulatorial e, em uma modalidade, podem ser conectar à nuvem por meio de redes de celular (3G/4G) . Em uma modalidade, o dispositivo de obtenção 112 fornece uma plataforma de informações médicas que compreende um ecossistema, interfaces de programação de interfaces (APIs), modelos, etc., para possibilitar o desenvolvimento de qualquer aplicativo, dispositivo ou

27/72 serviço no dominio de cuidados à saúde. Em uma modalidade, o dispositivo de obtenção 112 sustenta tanto a fonte aberta quanto os produtos proprietários. Visto que os dispositivos de obtenção 112 são dotados de construída em conformidade com o Ato de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA) dos Estados Unidos, a independência da plataforma em relação às aplicações relacionadas aos cuidados à saúde é fornecida. Em uma modalidade, uma pluralidade de APIs é fornecida para possibilitar sincronização de um dispositivo médico, assim como, o desenvolvimento de software médico com o dispositivo de obtenção 112. Em várias modalidades, o dispositivo de obtenção 112 recebe os dados de uma pluralidade de fontes de entrada de parâmetros de terceiros e dispositivos médicos, tais como, ventiladores, bombas IV, dispositivos de captação de parâmetro de paciente, etc. 0 dispositivo de obtenção se conecta a um aparelho de rede de GHC que se conecta à nuvem 114. Em uma modalidade, o dispositivo de obtenção 112 também tem capacidade para operar como um dispositivo de apresentação. Por conseguinte, o dispositivo de obtenção 112 possibilita que o sistema funcione como um sistema de monitoramento de paciente e, ao mesmo tempo, potencializar em tempo uma a pluralidade de aplicativos de terceiros.

[067] Em uma modalidade, o dispositivo de obtenção tem capacidade para fornecer uma segunda comunicação de tecnologia (isto é, tecnologia de celular, tal como, 3G/4G) que fornece mensagem de alarme aos cuidadores. Em outra modalidade, o dispositivo de obtenção tem um indicador visual (tal como, um indicador de luz) ou um indicador de

28/72 áudio que fornece informações de alarme critico apenas, tais como, número de identificação de paciente ou o número do leito e o tipo de alarme (frequência cardiaca, respiração etc.).

[068] Os dados obtidos são consolidados e distribuídos na etapa 104 pela nuvem 114. Em uma modalidade, a nuvem é virtual e inclui todos os dominios. Em outras modalidades, a nuvem é colocalizada e inclui um ou mais dominios. A nuvem 114 fornece a potência de processamento para os algoritmos que funcionam nos dispositivos de obtenção 112, desse modo, atuando como um hub local. O uso de uma plataforma com base em celular existente possibilita potencializar a tecnologia de consumidor, desse modo, reduzindo o custo de fabricação/desenvolvimento de uma plataforma de consolidação de parâmetro separada. Em várias modalidades, a nuvem 114 possibilita que dispositivos móveis sejam conectados a pacientes e operem como monitores de pacientes dentro de um ambiente hospitalar. Em uma modalidade, a nuvem 114 também possibilita que dispositivos móveis sejam usados por enfermeiras e médicos para monitorar e cuidar dos pacientes em ambientes não hospitalares. Em outra modalidade, a nuvem 114 possibilita que os dispositivos móveis conectem pacientes em domicilio a cuidadores por meio de uma pluralidade de aplicativos e dispositivos médicos, especificamente, dispositivos de captação. Ainda em outra modalidade, a nuvem 114 possibilita que os dispositivos móveis para conectar entes queridos em casas de retiro aos cuidadores.

[069] Em várias modalidades, a nuvem 114 possibilita que o sistema opere de maneira eficiente mesmo quando redes

29/72 subjacentes não estão funcionando apropriadamente. Além disso, a nuvem 114 pode operar em qualquer infraestrutura de rede existente e não exige qualquer hardware/software especifico ou proprietário seja instalado para operação. 0 sistema é projetado para operar em um modo seguro em que pelo menos um dispositivo de monitoramento de paciente é operacional em um caso de falha de rede. No modo seguro de operação, pelo menos os alarmes que são locais a um paciente operariam até se um monitoramento central não está disponível. Caso a conexão ao GHC ou à rede não seja operacional, o dispositivo de obtenção e, opcionalmente, o GHC, têm capacidade para analisar a armazenar dados psicológicos de paciente e para fornecer mensagem de alarme na localização de paciente. 0 dispositivo armazena os dados e, quando a operação de rede é armazenada novamente, os dados são transmitidos à nuvem de GHC. As informações armazenadas podem ser os sinais psicológicos de paciente contínuos ou os pacotes de mensagens gerados para alarmar e outras informações. 0 dispositivo de obtenção também pode ser adaptado para receber e apresentar dados psicológicos de paciente completos.

[070] Em várias modalidades, a nuvem 114 compreende dados obtidos de um ou mais hospitais ou centros médicos armazenados remotamente de cada um dos hospitais ou dos centros médicos. O armazenamento dos dados de paciente na nuvem 114 elimina os atrasos de processamento associados a um sistema de gerenciamento de banco de dados regular instalado em uma organização. Por conseguinte, a nuvem 114 possibilita que consultores de terceiros, assim como, cuidadores localizados remotamente analisem os dados

30/72 armazenados na mesma. A nuvem também possibilita que aplicativos de terceiros analisem os dados armazenados na nuvem 114, permitindo o processamento de dados fisiológicos e de outros dados de paciente a de múltiplas fontes. Além disso, a nuvem 114 possibilita a triagem remota de pacientes. Esse recurso pode fornecer um imenso uso nas arenas de conflito militar e áreas de desastre, assim como, em mercados emergentes e em desenvolvimento.

[071] Após a distribuição, os dados são apresentados na etapa 106 em dispositivos de exibição 116 incluindo, em várias modalidades, PCs tradicionais, computadores do tipo tablet, telefones inteligentes e visores montados em parede. Em várias modalidades, os dados médicos podem ser exibidos em qualquer dispositivo de exibição disponível a infraestrutura de sistema 100. O sistema não limita o visor de dados a dispositivos de visor proprietários. O sistema também permite apresentação simultânea de dados de paciente a múltiplos dispositivos múltiplos localizados em uma pluralidade de localizações.

[072] Em uma modalidade, o sistema do presente relatório descritivo fornece uma pluralidade de serviços com base em nuvem, tais como: Paciente Resolver, Dispositivo Resolver, Mecanismo de Politica, Orquestração e Gerenciamento. Por exemplo, um solucionar para paciente ou um serviço solucionador de dispositivo determines a cuidador e/ou um profissional médico que está em uma localização mais próxima a um paciente em necessidade de cuidados médicos. Em várias modalidades, o serviço solucionador de paciente compreende recursos, tais como, catálogo de paciente, mapa de identificação de

31/72

paciente	r	gerenciamento	de PHI e	! mapa	de	seção.	0
serviço	solucionador de	dispositivo	compreende	recursos,
tais como	gerenciamento	de dispositivo e	catálogo	de
seção.	0	serviço de mecanismo de	Politica	compreende
recursos	r	tais como	distribuição, '	'politica	de
segurança,	controle de	acesso e	aumento	de	alarme.	0
serviço	de	orquestração	compreende	recursos		tais como,
fluxos	de	trabalho e '	fluxos de	dados.	0	serviço	de

gerenciamento compreende recurso, tais como, gerenciamento de dominio, configuração, gerenciamento de atualização. Um painel central possibilita que uma organização fornecedora cuidados à saúde configura o paciente resolver, o dispositivo resolver e o mecanismo de Politica com base em políticas especificas da organização por todas as instalações da organização. 0 painel central garante que todos os dispositivos estão em conformidade com as políticas e estabelece um padrão uniforme de cuidados para pacientes. Os serviços com base em nuvem fornecem o mapeamento inteligente de informações de alarme de paciente para o cuidador apropriado com base na localização, proximidade, disponibilidade e conjunto de habilidades.

[073] Em uma modalidade, o sistema do presente relatório descritivo fornece uma pluralidade de aplicativos da web, tais como: porta de comunicações (bidirecional) de sistema de saúde sete (HL7), aplicativos de paciente e familiares, aplicativos de cuidador, aplicativos de arquivamento e de impressão e aplicativos de administração e de painel.

[074] Na etapa 102, os dispositivos de obtenção 112 estão obtendo ativamente dados clinicos do paciente. Além

32/72 disso, os dispositivos de obtenção 112 funcionam como um retrocesso tanto para os alarmes quanto para o visor de dados, caso ocorra uma falha do sistema de maneira geral. A inclusão dos dispositivos de obtenção 112 como reforço embutido ajuda a diminuir os custos de sistema e a minimizar a complexidade de sistema. As funções da nuvem 114 na etapa 104 incluem, porém sem limitação, uma descoberta de dispositivo e de serviço, distribuição e armazenamento de dados, controle de segurança e de política, geração de relatório de cuidados ao paciente e métricas e fluxo de trabalho de sistema. O sistema de nuvem possibilita o licenciamento de dispositivos, aplicativos e recursos da nuvem (mercado) e, então, a medição e realização de logon subsequente do uso de dispositivos e de aplicativos à medida que são usados. Os exemplos incluem o número de tipos de parâmetros ligados a pacientes específicos e por qual período de tempo, o número de dispositivos ativos na rede e o número de vezes que um recurso particular é usado. O conhecimento do real uso de dispositivos, aplicativos e recursos possibilita modelos de faturamento novos e únicos. Os exemplos podem incluir pagamento pelo uso por uma análise específica, faturamento escalável com base no número de pacientes monitorados pelo sistema, faturamento escalável com base o nível de acuidade do paciente (isto é, número de parâmetros que são monitorados). OS Sistemas de monitoramento de paciente tradicionais são vendidos como itens de equipamento de capital. A capacidade da nuvem sistema mova as compras de equipamento de capital a um modelo de serviço. Os dispositivos de visor 116 incluídos na etapa 106 fornecem o

33/72 visor de dados clínicos, expressão de alarme e supervisão paciente geral. Além disso, em uma modalidade, cada dispositivo de exibição 116 inclui uma interface de usuário gráfica (GUI) para permitir que cuidadores realizem deveres administrativos.

[075] Em uma modalidade, os dispositivos de obtenção 112 estão localizados tanto na instalação do cuidador quanto na residência do paciente e são extensíveis para ocasionar importações de dispositivos de fornecedor independente de hardware (IHV) e de sistema estrangeiro. Em uma modalidade, o aparelho de rede de GHC está localizado na instalação do cuidador e é extensível para acomodar aplicativos de fornecedores de software independentes (ISV) e interfaces de sistema estrangeiro. Em uma modalidade, os dispositivos de visor 116 podem estar localizados em qualquer local e são extensíveis para acomodar aplicativos de ISV.

[076] A Figura 1B ilustra uma situação de uso exemplificativa da presente invenção em uma unidade de tratamento intensivo (ICU) 101 de um hospital. Um dispositivo de obtenção 112 com capacidade para detectar uma pluralidade de parâmetros por meio de dispositivos de captação 113 é usado para medir e para coletar os dados de paciente. Os visores de monitor no de cabeceira 122 são acoplados ao dispositivo de obtenção 112 por meio de uma conexão por Ethernet para exibir uma estatística vital do paciente vital. O dispositivo de obtenção 112 também é acoplado a uma pluralidade de monitores de paciente, tais como, um monitor de enfermeira 124, um visor de monitor exclusivo fora do quarto do paciente 12 6, um monitor de

34/72 sistema de comando de incidente (ICS) 128 e um monitor de estação central 129. 0 dispositivo de obtenção 112 e a pluralidade de visores são acoplados à nuvem 114 fornecida pelo presente relatório descritivo. A nuvem 114 é, por sua vez, acoplada a uma plataforma de armazenamento de dados 144 para armazenar os dados relacionados ao paciente. A nuvem 114 possibilita que os cuidadores 152 acessem os registros do paciente por meio de um dispositivo de exibição móvel 116 e também possibilita que a familia do paciente 154 monitore a situação do paciente por meio de um dispositivo de exibição móvel 116 em uma localização longo de um ambiente hospitalar. A nuvem 114 também possibilita a análise combinatória de múltiplos parâmetros psicológicos coletados ao longo do tempo. Isso inclui dispositivos sensores desenvolvidos como parte do sistema e dispositivos sensores de terceiros.

[077] A Figura 1C ilustra uma situação de uso exemplificativa de sistema do presente relatório descritivo em uma enfermaria geral 103 de um hospital. Um dispositivo de obtenção 112 é usado como uma plataforma de consolidação de parâmetro que recebe os dados médicos do paciente, tais como, frequência cardiaca (HR), frequência respiratória, etc. Na modalidade retratada, o dispositivo de obtenção 112 também atua como o monitor de cabeceira do paciente. O dispositivo de obtenção 112 é acoplado à nuvem 114 fornecida pelo sistema do presente relatório descritivo. A nuvem 114 é, por sua vez, acoplada a uma plataforma de armazenamento de dados 144 para armazenar dados relacionados ao paciente. Além disso, a nuvem 114 é acoplada uma unidade de vigilância 136 para exibir as

35/72 estatísticas vitais de todos os pacientes admitidos na enfermaria geral. A nuvem 114 possibilita que os cuidadores 152 acessem os registros do paciente por meio de um dispositivo de exibição móvel 116 e também possibilitem que a família do paciente 154 monitore a situação do paciente status por meio de um dispositivo de exibição móvel 116 em uma localização longe de um ambiente hospitalar. A nuvem sistema possibilita que a família acesse as informações de cuidados ao paciente e revisem o histórico de cuidados ao paciente, o fluxo de trabalho, confirme que recebam atualizações nas instruções de alta hospitalar e revisão de faturamento, assim, reduzindo potencialmente os erros de cuidados ao paciente.

[078] A Figura 1D ilustra uma situação de uso exemplificativa do sistema do presente relatório descritivo em uma situação domiciliar 105. Um dispositivo de obtenção móvel 112, tal como, um celular ou outro dispositivo separado, é instalado na residência do paciente para uso como uma plataforma de consolidação de parâmetro que recebe os dados médicos paciente, tais como, frequência cardíaca (HR), frequência respiratória, nível de glucose, etc. O dispositivo de obtenção 112 também atua como uma doca de monitoramento da residência do paciente. O dispositivo de obtenção 112 é acoplado à nuvem 114 fornecida pelo sistema do presente relatório descritivo. A nuvem 114 é, por sua vez, acoplada a uma plataforma de armazenamento de dados 144 par armazenar os dados relacionados ao paciente. A nuvem 114 é acoplada, por sua vez, a uma pluralidade de monitores, tais como, um monitor da enfermeira 124, um monitor de ICS 128, e um monitor de

36/72 estação central 129 para exibir as estatísticas vitais do paciente em tempo real. A nuvem 114 possibilita que os cuidadores 152 acessem os registros do paciente e monitorem a saúde do paciente por meio de um dispositivo de exibição móvel 116 e também possibilitem que a família do paciente 154 monitore a situação de paciente status por meio de um dispositivo de exibição móvel 116 em uma localização longe de um ambiente hospitalar.

TOPOGRAFIA DO SISTEMA [07 9] A Figura 2 é um diagrama de blocos que ilustra uma topografia física exemplificativa de uma modalidade do

sistema de	informação	de	dados médicos 200	do presente
relatório	descritivo.	Em	uma	modalidade, o	sistema	200
inclui	dispositivos		de	captação/obtenção	212

(correspondentes ao dispositivo de captação 112 e/ou dispositivo de obtenção 113 da Figura IA) para a obtenção de dados de paciente e de dispositivos de visor 216 (correspondentes ao dispositivo de exibição 116 da Figura IA) para a apresentação de dados de paciente. Em outra modalidade, o sistema 200 inclui dispositivos com capacidade tanto para obter dados e apresentar dados. Um monitor de paciente tradicional pode funcionar tanto como um dispositivo de obtenção quanto um dispositivo de apresentação. O sistema 200 também inclui uma nuvem 214 que compreende uma pluralidade de conectores de saúde global (GHC) 213, 215 que são responsáveis pela consolidação e pela distribuição de dados de paciente. Um GHC é um aparelho de hardware de rede com software integrado que se liga à rede. Em uma modalidade, o sistema 200 inclui tanto os GHCs 215 que colocalizados dentro da instalação do

37/72 cuidador, por exemplo, um hospital 220, quanto os GHCs 213 que são localizados dentro da nuvem 214. Os GHCs 213, 215 atuam para entrar em contato com os dispositivos de obtenção 212 e os dispositivos de visor 216 do sistema 200. Em uma modalidade, os dispositivos de obtenção 212 e os dispositivos de visor 216 são conectados por meio de uma nova midia ou malha de comutação de troca de mensagens. A nuvem 214 conecta todos os GHCs 213, 215 como pares em um suporte principal roteável redundante e liga todos os dispositivos de captação 212 e dispositivos de visor 216 para estabelecer a vigilância de paciente global. Em outras palavras, todos os dados de paciente são reunidos e distribuídos pela nuvem de modo que, em todas as vezes e dado o acesso apropriado, qualquer dispositivo de exibição pode apresentar dados par qualquer paciente através do sistema.

[080] Conforme visto na Figura 2, os dispositivos de captação 212 podem ser localizados sem um hospital 220, uma clinica 222 e na residência do paciente 224. Os dispositivos de visor podem estar localizados em um hospital 220, uma clinica 222 e com cuidadores 226. Os dispositivos de captação 212 e os dispositivos de visor 216 em hospitais 220 e clinicas 222 são conectados por meio de redes de hospital 230 e redes de clinica 232 respectivamente e todos os dispositivos são interconectados através da nuvem 214 por meio da internet 234.

[081] Em uma modalidade, os dispositivos de captação são denominados de sistemas dispositivo de obtenção e incluem qualquer dispositivo que obtém e publica dados em um formato de seção de sistema. Tais dispositivos incluem,

38/72 porém sem limitação, monitores de cabeceira fixos tradicionais, dispositivos desgastáveis com fator de forma pequeno, e dispositivos virtuais, tais como, registrados dados digitais e importações de sistema estrangeiro. 0 fluxo de informações começa com o sensor que fornece dados em formato bruto ao dispositivo de obtenção de sistema. Um aplicativo de driver no dispositivo de obtenção processa os dados em formato cru em dados de parâmetro. Os dados de parâmetro são, então, publicados pelo dispositivo de obtenção no formato de seção de sistema e transferidos por upload à rede. 0 formato de sessão de sistema é uma forma de dados de parâmetro reconhecido pela nuvem que é distribuída aos dispositivos de visor.

[082] Em uma modalidade, um único dispositivo de obtenção de sistema é atribuído a um único paciente e não há compartilhamento de dispositivos de obtenção por pacientes. Múltiplos sensores e parâmetros são agrupados pelo único dispositivo de obtenção em uma sessão única par um único single paciente. Em uma modalidade, um dispositivo de obtenção tem um repositório de memória local por pelo menos 5 dias de dados de paciente. Os dados armazenados localmente são uma réplica exata dos dados transferidos por upload à nuvem e são publicados por meio de um modelo de replicação. Em uma modalidade, o sistema inclui a replicação de dados transitivos par a par. Uma maioria dos bancos de dados significativos dentro da rede é replicada através de múltiplas localizações com uso de um modelo par a par. O modelo par a par administra automaticamente a replicação transitiva e replicação seletiva com base em uma heurística de custo/beneficio. A memória local fornece

39/72 histórico de dados e uma cópia de segurança, caso ocorra uma falha do sistema geral.

[083] Em uma modalidade, dispositivos de exibição são referidos como dispositivos de apresentação de sistema e incluem quaisquer dispositivos que exibem dados e incluem opcionalmente alarmes. Tais dispositivos incluem, porém sem limitação, PCs tradicionais, computadores do tipo tablet, telefones inteligentes e monitores de parede. Os dispositivos de apresentação são baseados em navegador, suportando um ambiente para trabalhar em qualquer local. Em uma modalidade, os dispositivos de apresentação de sistema incluem uma GUI e fornecem uma funcionalidade de estação de trabalho de profissional de saúde. Por exemplo, em várias modalidades, a GUI dos dispositivos de apresentação fornece gerenciamento e supressão de alarme, gerenciamento de paciente (admissão/liberação), associação de paciente/sessão e funcionalidade de análise de dados. Em uma modalidade, todos dispositivos de apresentação incluem uma interface de usuário comum com linguagem de marcação de hipertexto 5 (HTML5) como a fundação de interface.

[084] Referindo-se novamente à Figura 2, a nuvem de sistema 214 inclui tanto conectores de saúde global colocalizados (GHCs) 215 e GHCs em nuvem 213, todos conectados para formar o suporte principal de nuvem de sistema. Cada GHC colocalizado 215 é um aparelho de rede pequeno que é plugado, ativado e usado no ambiente do profissional de saúde. Em uma modalidade, aproximadamente 200 a 500 leitos são alocados a cada GHC colocalizado. Os GHCs em nuvem 213 garantem o alcance global do suporte principal e, em uma modalidade, aproximadamente 500.000

40/72 leitos são alocados a cada agrupamento de GHC em nuvem (8 GHCs em nuvem). A nuvem de sistema 214 hospeda o diretório de troca de mensagens. Em uma modalidade, todos os GHCs 213, 215 são pares e todos os dispositivos de obtenção 212 e dispositivos de apresentação 216 podem se conectar a qualquer GHC 213, 215. Cada GHC 213, 215 consolida os dados de sessão dos dispositivos de obtenção 212 e distribui os dados para os dispositivos de apresentação 216. A nuvem de sistema inclui catálogos de domínio organizados por contas, pacientes e ativos. Além disso, em uma modalidade, os GHCs são completamente replicados para redundância de failover verdadeira.

[085] Em uma modalidade, a nuvem de sistema inclui pelo menos um domínio em nuvem de sistema e uma pluralidade de departamentos em nuvem de sistema. Um domínio é a camada superior logicamente isolada da nuvem de sistema e não fornece nenhum acesso entre domínios. O domínio corresponde tipicamente a um hospital e é escalável de 10 leitos a mais de 1.000 leitos com custos correspondendo ao número de leitos. Todas as funções do dia a dia do sistema de informações ocorrem no domínio. Cada perspectiva do usuário do domínio é o mundo inteiro do sistema. Em outras palavras, cada usuário é único e isolado e, se dado o acesso apropriado, pode ver todos os outros usuários dentro do mesmo domínio. Todos os GHCs, dispositivos de obtenção e dispositivos de apresentação pertencem a um domínio. Em uma modalidade, um dispositivo externo pode ser usado em um domínio, mas o mesmo deve ser primeiro autorizado a funcionar nesse domínio. O domínio de nuvem de sistema contém todos os dados de hospital, incluindo, porém sem

41/72 limitação, contas para todos os profissionais de saúde, informações de saúde protegidas de paciente (PHI), dados de sessão de paciente, registros de ativo, informações de departamento de nuvem de sistema e predefinições que definem as definições de parâmetro exigidas para hospital.

[086] Cada departamento de nuvem de sistema representa uma divisão dentro de um domínio e funciona para assistir em fluxos de trabalho. Cada departamento corresponde tipicamente a uma unidade de hospital e é considerado uma divisão suave, com quase nenhuma restrição em acesso de departamento cruzado. Profissionais de saúde, pacientes e dispositivos têm todos um departamento de residência de modo que os profissionais de saúde possam focar rapidamente nos pacientes em seu departamento. A maioria dos departamentos não são restritivos e não há nenhuma imposição no sistema de modo que os profissionais de saúde possam comutar os departamentos conforme desejado. Todos os dispositivos herdam um departamento na inicialização que é determinado pelo departamento do profissional de saúde que inicia uma sessão. Em uma modalidade, determinados departamentos são restritos e exigem autorização prévia antes de ser acessada por um profissional de saúde pela primeira vez. Por exemplo, os profissionais de saúde não teriam a capacidade de acessar um departamento de cuidados psiquiátricos sem obter primeiro a autorização. Cada departamento rastreia adicionalmente eventos de faturamento para orçamento.

[087] Em uma modalidade, a nuvem de sistema inclui adicionalmente uma organização de nuvem de sistema que é usada para o faturamento consolidado para múltiplos

42/72 domínios .

SEGURANÇA DE SISTEMA [088] Cada domínio do sistema de informações de dados médicos do presente relatório descritivo é designado como um jardim murado. Cada domínio incluirá acesso rigidamente restrito, mas uma vez dentro, um usuário terá a capacidade de se movimentar livremente. A segurança do sistema é construída como um modelo permissivo com registro em log e auditoria generalizada de todas as atividades. Solicitações incomuns no sistema serão tratadas em um cenário de quebre o vidro. Por exemplo, em uma modalidade, os usuários que solicitam acesso incomum serão apresentados com uma questão do tipo você tem certeza? seguida por um aviso de auditoria antes de proceder. Embora o sistema forneça acesso amplo aos usuários, algumas restrições estão ainda em vigor quando necessário. Por exemplo, uma enfermeira não terra a capacidade de apagar todas as contas. A segurança do sistema de informações de dados médicos do presente relatório descritivo é designada de modo que o mesmo não possa impedir nunca um profissional de saúde de fornecer cuidados ao paciente. Como tal, o sistema não dependerá da segurança de IT, criptografia,

redes privadas	virtuais (VPN)	ou plataforma	de	sistema
operacional (OS)	•
[089] Será	exigido	que os	profissionais	de	saúde e
administradores	tenham	contas	com credenciais	de	senha e

nome de usuário para acessar o sistema por meio dos dispositivos de obtenção, dispositivos de apresentação e da internet. Em uma modalidade, os pacientes e parentes terão acesso especial limitado por meio da internet e não

43/72 exigirão contas. Em uma modalidade, os usuários com contas são também fornecidos com um PIN como credenciais de forma curta. 0 PIN é destinado para o uso quando será inadequado entrar credenciais completas, tal como em um teclado numérico. 0 PIN é conectado diretamente a um papel designado e é usado para comutar contas quando múltiplos usuários iniciaram uma sessão em um dispositivo de obtenção ou apresentação. Além disso, os PINs são armazenados em armazenamento intermediário de provisão em todos os

dispositivos	para	o acesso de emergência quando	a rede está
inoperante.
[090] A	cada	conta	é designado	um grupo	de papéis
permitidos.	Cada	papel	define um	conjunto	nomeado de

permissões definidas pela administração. Um usuário escolhe um papel e, portanto, permissões durante o inicio de sessão. Em uma modalidade, os papéis também especificam a lista de aplicativos permitidos. Os papéis podem ser somente alterados encerrando a sessão e, então, iniciando de novo a sessão. Múltiplos inícios de sessão a um dispositivo de sistema único devem todos compartilhar o mesmo papel. As permissões designadas a cada papel incluem, porém sem limitação, acessar PHI, admitir um paciente e visualizar dados. Cada conta recebe a permissão somente por ser designado um papel. Em outras palavras, não há nenhum direito de nível de conta. Uma federação de diretório ativa mapeia grupos de diretório a papéis, permitindo que uma maioria de gerenciamento de conta seja realizada no diretório ativo.

[091] Todos os dados, incluindo mensagens e tráfego de rede, são criptografados com o uso do padrão de

44/72 criptografia avançada 256 (AES-256). Além disso, todos os dispositivos de sistema são validados antes de serem conectados à nuvem de sistema. Em uma modalidade, o ponto de descriptografia está no ponto de conexão de troca de mensagens de dispositivo, conforme o OS de dispositivo não é considerado confiável pelo sistema. Para impedir o acesso indesejado de informações sensíveis, os dados de PHI são segregados de dados clínicos ou sessões em banco de dados criptografados separados. 0 acesso não autorizado a um banco de dados único não comprometerá as PHI protegidas por HIPAA. 0 sistema inclui o gerenciamento de chave robusto e caução de chave em que as chaves primárias são travadas em cofres que são chaveados a credenciais. Os cofres em armazenamento temporário de provisão permitem o início de sessão mesmo quando a rede está inoperante. A nuvem e as redes locais utilizam a mesma criptografia e as cópias de segurança em nuvem são também criptografadas.

[092] Em uma emergência devido a falhas de rede, ataque por um vírus de software ou outras fontes, o sistema pode desligar a conexão ao GHC e operar como um dispositivo autônomo para obter e apresentar os dados fisiológicos com sistema de mensagens de alarme local.

[093] O sistema utiliza a codificação Lua e máquinas virtuais (VM) conforme mostrado na Figura 3 para alcançar um sistema fechado para a segurança confiável e um sistema portátil extensível por terceiros. A VM cria um aplicativo isolado em que, se o software de entrada maligno for conectado ao sistema através do dispositivo de obtenção, o software é contido à máquina virtual isolada do hardware e software de sistema. No caso de um ataque, o sistema

45/72 desliga a VM enquanto o sistema pode continuar a operar para os outros aplicativos de monitoramento de paciente.

APLICATIVOS DE SISTEMA [094] Todos os dispositivos do sistema de informações de dados médicos do presente relatório descritivo funcionam em um aplicativo de portal de sistema que é a pilha de software base do sistema. Cada plataforma de OS (PC, Mac, iOS, Android) tem um aplicativo de portal especifico construído para esse OS que é entregue ao dispositivo por meios específicos para OS (por exemplo, iTunes). O aplicativo de portal de sistema é empacotado como um binário monolítico para cada plataforma de OS-alvo. Simplesmente executar o aplicativo de portal de sistema torna o dispositivo um dispositivo de obtenção de sistema, dispositivo de apresentação de sistema ou ambos. O aplicativo de portal de sistema é também usado nos GHCs e servidores de web.

[095] A inscrição de dispositivo é exigida antes do aplicativo de portal de sistema poder ser usado. A inscrição cria um registro de ativo no dominio de sistema para uma combinação do dispositivo e do aplicativo de portal de sistema. A inscrição também designa um ID de conexão de troca de mensagens de dominio para endereçamento de mensagens e designa chaves e cofres de caução para o armazenamento local criptografado. A inscrição pode ser realizada off-line ou diretamente no dispositivo, se permitido. Os dispositivos externos são permitidos, mas exigem inscrição para garantir que o dispositivo não seja poluido.

[0 96] A Figura 3 é um diagrama de blocos que ilustra a

46/72 arquitetura de software 300 de uma modalidade do aplicativo de portal de sistema. O aplicativo de portal é um aplicativo monolítico carregado como um processo de OS. O aplicativo de portal inclui uma base de aplicativo de portal 310 que instancia múltiplos blocos de mecanismo clínico integrados 320 para hospedar os aplicativos de sistema conforme necessário.

[097] A base 310 contém uma camada de abstração de OS (OSAL) 311 que isola o aplicativo de portal de idiossincrasias de sistema operacional 305 e lida com inicialização, armazenamento e outras interfaces de OS. A OSAL 311 é a única parte do aplicativo de portal que é específico para OS, maximizando a reutilização de código. A base 310 também inclui uma pluralidade de bibliotecas 312 que fornecem suporte funcional para aplicativos executáveis escritos, em uma modalidade, na linguagem de programação Lua. As bibliotecas 312 incluem segurança/criptografia, lite de linguagem de consulta padrão (SQLite), zlib, interface de usuário/experiência dede usuário (UI/UX) e outras bibliotecas mistas. Uma pessoa com habilidade comum na técnica reconhecerá que Lua é uma linguagem de programação de plataforma cursada de peso leve designada como uma linguagem de script relativamente simples com semântica extensível. Também incluído na base 310 está um mecanismo de Lua 313 para executar o código de aplicativo de Lua nos blocos de mecanismo clínicos integrados 320. O mecanismo de Lua 313 também gerencia um agrupamento de partes de Lua 314 para blocos de código compartilhado. A base 310 também contém um gerenciador de bloco de mecanismo clínico integrado e uma pilha de protocolo de troca de

47/72 mensagens completa 315. A base de aplicativo de portal 310 funciona essencialmente como um hospedeiro de Lua sofisticado e não contém nenhum código ativo.

[098] Cada bloco de mecanismo clínico integrado 320 funciona como um sítio usado para executar aplicativos de sistema. Os dispositivos de obtenção de sistema e dispositivos de apresentação de sistema representam, cada um, um único bloco de mecanismo clínico integrado 320. Os servidores da web instanciam um bloco por conexão de web ativa com manipulação especial de IDs de ponto de conexão por meio de um agrupamento de IDs por servidor. Cada bloco 320 contém seu próprio ponto de conexão de troca de mensagens 321 de modo que cada bloco seja visto pela nuvem como um dispositivo de sistema. Além disso, cada bloco tem sua própria conexão TCP/IP, início de sessão e permissões. Cada bloco 320 contém adicionalmente uma pluralidade de aplicativos de Lua individuais 322, incluindo aplicativos de inicialização e sistema, que são executados pelo mecanismo de Lua 313 da base de aplicativo de portal 310. A base 310 mantém um agrupamento de encadeamento para executar aplicativos de Lua 322 nos blocos 320. Os encadeamentos são despachados para instâncias de Lua conforme necessário. Os aplicativos de Lua 322 são acionados por evento. Todo código não Lua é idêntico por todos os aplicativos de portal de sistema.

[099] 0	aplicativo	de	inicialização	de Lua é	ligado	ao
aplicativo	de portal	de	sistema e	define o	tipo	de
dispositivo	(obtenção	ou	apresentação)	0 aplicativo	de
inicialização é o único	aplicativo	enviado	dentro	do
binário de	aplicativo	de	portal e sua única	função	é

48/72 iniciar uma sessão para a nuvem e carregar o aplicativo de sistema. 0 aplicativo de sistema contém a funcionalidade real do aplicativo de portal e serve para carregar os aplicativos de Lua conforme desejado.

[100] Os aplicativos de Lua são vendidos em um mercado online e armazenados como ativos. Todos os aplicativos são entregues para o aplicativo de portal no dispositivo, carregados na hora (JIT) e executados por meio da troca de mensagens. As atualizações de aplicativo de Lua são colocadas no catálogo de ativo e desacopladas de atualizações de aplicativo de portal mais enfadonhas.

[101] A Figura 4 é um fluxograma que ilustra as etapas envolvidas na inicialização de um dispositivo de obtenção no sistema de informações de dados médicos do presente relatório descritivo. Na etapa 402, um aplicativo de inicialização pré-carregado carrega o aplicativo de sistema de dispositivo de obtenção apropriado. Então, na etapa 404, o aplicativo de sistema de dispositivo de obtenção inicializa o dispositivo pelo registro para eventos de detecção de sensor e carregamento de ativos apropriados. Um novo sensor é conectado na etapa 40 6 e o aplicativo de sistema recebe um evento conectado de sensor, fazendo com que o aplicativo de sistema para consultar o sensor para a identificação para determinar a classe e o tipo de sensor. O aplicativo de sistema também consulta o catálogo de ativo no domínio para o driver de aplicativo correspondente e, então, carrega o driver do catálogo ou usa uma cópia em armazenamento intermediário de provisão. O novo driver conecta-se ao sensor na etapa 408, inicializando-se as definições de predefinições e registrando o parâmetro no

49/72 diretório. Na etapa 410, os dados de parâmetro são gravados localmente e disponível para assinatura. Isso compreende a capacidade de ligar e usar em que o sistema detecta automaticamente o tipo de dispositivo de sensor e configura esse dispositivo para realizar interface com o dispositivo de obtenção, alarmes de sistema e apresentação de dados fisiológicos.

PROTOCOLO DE TROCA DE MENSAGENS [102] O sistema para fornecer cuidados ao paciente do presente relatório descritivo usa um protocolo único para codificar as informações a serem transmitidas por toda a rede. Quando as mensagens são enviadas por meio do protocolo de troca de mensagens de sistema, um transmissor envia a mensagem com um programa de computador pequeno que usa uma linguagem de script-padrão industrial. Em uma modalidade, a linguagem de script é Lua. Quando o receptor recebe a mensagem, o mesmo executa o programa contido e, como um resultado da execução, recebe os dados desejados. A execução da mensagem rende naturalmente os dados que já foram completamente decodificados e estão prontos para serem consumidos pelo receptor sem nenhum processamento adicional necessário. O protocolo de troca de mensagens padroniza a execução da mensagem no receptor em vez de padronizar o conteúdo real da mensagem. Operando-se de tal modo, o protocolo de troca de mensagens altera o contrato entre o transmissor e o receptor de definir o conteúdo de uma mensagem para definir o resultado da execução de uma mensagem.

[103] O protocolo de troca de mensagens fornece maior flexibilidade na codificação de mensagens permitindo que o

50/72 transmissor crie qualquer programa que desejar ao enviar uma mensagem, contanto que a execução final do programa renda os dados esperados. Além disso, novas encapsulações de mensagem podem ser desenvolvidas sem o receptor precisar estar ciente das mesmas, evitando assim o problema do transmissor e receptor terem que ser atualizados simultaneamente. A troca de mensagem também elimina a sobrecarga de decodificação fornecendo-se dados finais em

uma forma utilizável uma vez	que	o programa contido	foi
executado.
[10 4] Em uma	modalidade,	a troca de mensagem é	uma
troca central	confiável	que	estabelece um	link

criptografado entre ela própria e cada transmissor e receptor. O link entre a troca de mensagens e cada transmissor e receptor individuais precisa ser estabelecido somente uma vez por transmissor e receptor. Um transmissor criptografa localmente uma mensagem para enviar uma chave de uma vez (OTK) . O transmissor, então, envia a mensagem criptografada com a OTK com o uso de chaves trocadas com a troca de mensagens. Já que a troca de mensagens é uma troca confiável, a mesma conhece as chaves de ambas as partes e realizará a descriptografia da OTK e, então, realizará nova criptografia o receptor. A troca de mensagens envia, então, a OTK recriptografada, juntamente com a mensagem para o receptor. Em uma modalidade, o protocolo descrito pode ser usado através de múltiplas trocas em localizações diferentes. A troca de mensagens tem somente que descriptografar e criptografar a OTK e pode passar através da mensagem como tal, resultando na sobrecarga inferior na troca. A troca é sem conexão em que o transmissor e o

51/72 receptor não precisam nunca trocar as chaves um entre o outro. A troca de chave é feita na e pela troca de mensagens confiável e precisa apenas ser estabelecida uma vez por transmissor ou receptor. As chaves de mensagem são encapsuladas por meio da malha de troca de mensagens confiável (ponto a ponto), sem a necessidade de estabelecer conexões de ponto de extremidade, resultando na transferência de mensagem mais eficaz.

[105] Em uma modalidade, o transmissor embute sua lista de destinatários no cabeçalho de mensagem e envia a mesma para troca. A troca de mensagens replica a lista de destinatários e, então, transfere a mensagem para todos os receptores pretendidos. A troca de mensagens manipula toda a distribuição de mensagem, exigindo que o transmissor envie somente a mensagem uma vez independendo do número de destinatários. Isso permite que o transmissor reduza o consumo de energia. Além disso, já que a lista de destinatários é incluída no cabeçalho de cada mensagem, a operação de roteador tem a capacidade de permanecer sem informação de estado. Portanto, quando um dispositivo é móvel e se move para um novo GHC, o dispositivo simplesmente continua a enviar os dados para o novo GHC sem a necessidade de ressincronizar. A lista de assinaturas já está fixada em cada mensagem.

[106] Já que o código do transmissor está funcionando no receptor, é possível para o programa contido executar qualquer ação legal no espaço de execução do receptor. Em uma modalidade, a geração de uma confirmação de retorno é realizada pelo transmissor que envia uma mensagem de troca que inclui a formação e a geração de uma confirmação de

52/72 retorno para o remetente original dos dados como uma parte do código contido na mensagem. Quando o receptor executa o script, outra mensagem de troca é formada pelo receptor e enviada para o remetente de dados original. Em outra modalidade, uma coleção das confirmações de retorno é também enviada para um servidor de coleção de dados. Nessa modalidade, o programa de script enviado pelo transmissor

inclui um programa	de	geração	de confirmação	de	retorno
direcionado para o	transmissor	e outro programa	de	geração
de confirmação de	retorno direcionado para o servidor de
coleção de dados.
[107] Portanto,	com	o uso	de uma linguagem	de	script

tal como Lua, qualquer mensagem no sistema de troca de mensagens tem a capacidade de gerar sua própria confirmação de entrega. Isso permite protocolos de nível mais alto para descrever sua própria semântica de validação de entrega sem precisar de suporte adicional da malha de troca de mensagens. Uma confirmação de retorno é apenas um exemplo de como as mensagens de troca podem ser usadas para codificar o comportamento complexo no receptor que não exige um protocolo mantido rigidamente entre o transmissor e o receptor.

[108] O protocolo de troca de mensagens de sistema manipula todas as comunicações entre os dispositivos individuais e entre os dispositivos e GHCs no sistema. A troca usa TCP/IPv4 ou TCP/IPv6 e DHCP sem nenhum outro provisionamento de rede necessário. A troca de mensagens monitora sempre e compreende uma topologia de conexão única simples. Cada dispositivo mantém uma única conexão TCP/IP a um GHC. Os GHCs interconectam-se um ao outro para formar

53/72 uma malha de comutação de modo que o sistema de mensagens de dispositivo para dispositivo não tenha conexão e informações de estado. Todas as conexões de firewall são expedidas sem nenhuma porta aberta necessária. A topologia simples resulta em um sistema de desempenho alto com latência baixa e comutação instantânea.

[109] Cada bloco de mecanismo clinico integrado de cada aplicativo de portal de sistema funciona como um ponto de conexão que hospeda a conexão TCP/IP real a um GHC. A desconexão/reconexão e migração de sub-rede são transparentes para outros aplicativos. A identificação de ponto de conexão é estabelecida quando o dispositivo e o aplicativo de portal são registrados com o sistema. Tipicamente, um único dispositivo inclui um aplicativo de portal com um bloco de mecanismo clinico integrado de modo que haja uma única conexão ao sistema. O ponto de conexão manipula todas as mensagens para todos os aplicativos em cada bloco de mecanismo clinico integrado.

[110] Os pontos de extremidade de mensagem são sempre aplicativos. Um ponto de extremidade único inclui o ID de dominio, ID de ponto de conexão e ID de aplicativo. Portanto, cada bloco de mecanismo clinico integrado pode ter apenas uma instância de uma execução de aplicativo. Em uma modalidade, um caso especial existe para catálogos de dominio que estão sempre em um GHC local. Os serviços bem conhecidos são mapeados a IDs de ponto de conexão polimórficos reservados. Em uma modalidade, os aplicativos podem registrar serviços com o GHC em que o serviço é um ID global que implica sequência e conteúdo de mensagem.

[111] A Figura 5 é um fluxograma que ilustra uma

54/72 modalidade das etapas envolvidas em uma troca de mensagens exemplificativas entre dois aplicativos. Dentro do bloco de mecanismo clinico integrado 1 530, o aplicativo APP1 535 cria uma mensagem para o aplicativo APP4 565 e envia a mensagem para seu ponto de conexão de troca de mensagens CPI 532 na etapa 505. O aplicativo APP1 535 é o primeiro ponto de extremidade EP1 e o aplicativo APP4 565 é o segundo ponto de extremidade EP2 da troca de mensagens. O aplicativo-alvo APP4 565 é endereçado no segundo ponto de extremidade EP2 do ponto de conexão de troca de mensagens CP2 562 dentro do bloco de mecanismo clinico integrado 2 560. A pilha de troca de mensagens em CPI 532 segmenta a mensagem e, na etapa 510, envia os segmentos de mensagem para GHC1 540. O GHC1 540 verifica o diretório e localiza CP2 562 em GHC2 550. Na etapa 515, o GHC1 540 envia os segmentos de mensagem para GHC2 550. O GHC2 550 recebe os segmentos de mensagem e envia os mesmos diretamente para CP2 562 na etapa 520. A pilha de troca de mensagens em CP2 562 recebe os segmentos e remonta a mensagem. Na etapa 525, CP2 562 envia a mensagem para o aplicativo-alvo APP4 565. Também ilustrados na Figura 5 são o aplicativo APP2 537 no bloco de mecanismo de circuito integrado 1 530 e o aplicativo APP3 567 no bloco de circuito integrado 2 560 que representa pontos de extremidade de troca de mensagens adicionais por meio de CPI 532 e CP2 562.

[112] Todas as mensagens são segmentadas, comprimidas e criptografadas para transmissão. A manipulação de todas as mensagens é realizada em cada extremidade pelos pontos de conexão. Os GHCs simplesmente comutam dados opacos. Enviar os segmentos de mensagens menores permitem a comutação mais

55/72 eficaz nos GHCs e impede mensagens de prioridade baixa grandes de bloquear mensagens de prioridade mais alta. Os segmentos são enviados de um primeiro ponto de extremidade, através de pelo menos um GHC e, então, para um segundo ponto de extremidade. Somente os cabeçalhos de segmento são criptografados e descriptografados conforme os segmentos saltam de um GHC para outro. Os segmentos são bloqueados em conjunto para enquadramento de rede ideal e são marcados com um GHC-alvo para fazer roteamento de salto mais rápido.

[113] Em uma modalidade, os GHCs que roteiam os segmentos de mensagem de troca usam um algoritmo de roteamento com base em custo que calcula e escolhe a rota melhor e mais rápida com o uso de métricas ponderadas. As métricas são automaticamente calculadas pela medição direta do desempenho de link durante o uso real. Nenhuma definição ou ajuste inicial é necessário. 0 protocolo de roteamento reage dinamicamente à congestão de rede subjacente, interrupções e alterações para evitar custos de nuvem desnecessários enquanto também preserva um fallback em nuvem completo no caso de falha de rede. Durante a operação, os GHCs trocam métricas de custo de roteamento para automatizar o equilíbrio de tráfego automático. Reagindo-se às medições diretas do desempenho de link real, o sistema roteia os segmentos eficazmente enquanto minimiza o uso de largura de banda.

[114] Em uma modalidade, o sistema para fornecer cuidados ao paciente do presente relatório descritivo reúne os dados em mensagens de tamanho razoável para minimizar a energia usada para transmitir um volume dado dos dados. A reunião dos dados em conjunto em mensagens

56/72 maiores resulta em um aumento no atraso entre quando uma mensagem é criada e quando a mesma é enviada para o receptor, mas exige menos energia do transmissor. Já que muitos transmissores em um ambiente de hospital podem ser dispositivos móveis, reunir as mensagens serve para prolongar a vida de bateria. Os exemplos de dados obtidos continuamente por dispositivos de transmissão incluem ECG, pressão sanguínea e formas de onda de oximetria de pulso. Em uma situação de não emergência, esses dados podem ser reunidos e enviados em conjunto para preservar energia. Mensagens urgentes, tais como alarmes clínicos de risco de vida ou mensagens de sistema críticas, serão enviadas individualmente e imediatamente.

[115] Conforme as mensagens são geradas pelos aplicativos de sistema, as mesmas são enfileiradas no ponto de controle (NCP). Parte do processo de enfileiramento inclui determinar a prioridade de mensagem. Por exemplo, em uma modalidade, as mensagens são etiquetadas como sistema, urgente, prioridade alta, média e baixa com as mensagens de prioridade mais alta enviadas primeiro. A reserva de largura de banda evita a privação da mensagem de prioridade baixa. As mensagens não urgentes de um aplicativo específico são sempre enviadas em ordem com mensagens urgentes e de prioridade alta causando a liberação de armazenamento temporário de IP. Em uma modalidade, uma opção de segundo plano defere as mensagens de prioridade mais baixa até o sistema enviar o próximo grupo de mensagens reunidas. Cada instância na qual o sistema envia um grupo de mensagens reunidas é chamado de sistema de pulsação. Em uma modalidade, a pulsação ocorrem em

57/72 uma frequência menor (0,5 a 10 Hz).

[116] Em uma modalidade, o sistema implanta um mecanismo de publicação e assinatura (Pub/Sub) que garante que os dados pretendidos para o uso por múltiplos assinantes ou receptores serão produzidos pelo dispositivo de fonte ou transmissor somente uma vez. Por exemplo, não é incomum para um dispositivo de monitoramento móvel usado no sistema para ter múltiplos consumidores dos dados obtidos do dispositivo. Um monitor móvel típico pode estar gerando alarmes e sinais vitais que são usados por múltiplos profissionais de saúde (enfermeiro, enfermeiro de supervisão, médico), todos os quais podem estar monitorando o mesmo paciente em diferentes dispositivos (alguns dos quais podem ser móveis). Além disso, os sinais vitais e formas de onda em tempo real e tendências podem ser continuamente exibidos em monitores centrais ou de cabeceira que são conectados diretamente à red.

[117] Nesse exemplo, cada dispositivo do profissional de saúde (e as unidades diretamente conectadas) terra assinaturas ativas aos dados sendo produzidos pelo monitor móvel. Nesse caso, o monitor móvel transmite os dados de monitoramento uma vez a partir do dispositivo para o GHC mais próximo. A mensagem que é transmitida incluirá os endereços de todos os destinatários dos dados do

dispositivo.	0 GHC interpretará a	lista de endereços	e
garantir os	dados duplicados	sejam	enviados para	todos	os
destinatários.
[118] 0	CP no dispositivo	de fonte monitorará	todas	as
assinaturas	ativas para os	dados	e garantirá	que	as
informações	de roteamento	para	cada assinante sejam

58/72

incluídas no	pacote de	mensagens único	que	é enviado	ao
GHC. Quando	os dados	forem	recebidos	pelo	GHC, criarão
novas mensagens que	são	vinculadas	a	cada um	dos
dispositivos	assinantes	. Deve	-se notar que a	duplicação	dos

dados nesse ponto não é mais dispendioso devido ao fato de que o GHC é um dispositivo conectado diretamente alimentado pela parede com uma conexão de rede rápida.

[119] 0 protocolo de troca de mensagens é otimizado para dispositivos de baixa potência. Em uma modalidade, o controle de fluxo de saida é opcional à medida que não é necessário em dispositivos que não são limitados por potência. A opção em plano de fundo diminui o tráfego e otimiza o uso de rádio de WiFi através do envio de mensagens em sequência. Além disso, os dados de publicação/assinatura (Pub/Sub) são enviados apenas uma vez a partir de um dispositivo. A redução do tráfego de WiFi total aprimora a vida útil da bateria do dispositivo e reduz a carga na rede. 0 batimento cardíaco administra alertas quando uma conexão cair e também envia atualizações sobre o estado, as métricas, a lista de baias, e sobre localização/presença.

[120] A Figura 6 é um fluxograma que ilustra uma modalidade do fluxo de mensagens a partir de um par de aplicativos no sistema de informações de dados médicos do presente relatório descritivo. Na etapa 605, o aplicativo APP1 630 e o aplicativo APP2 640, cada um, envia uma mensagem ao ponto de conexão/empilhamento de troca de mensagens 650 para a entrega a um outro aplicativo (não mostrado). A troca de mensagens 652 comprime e criptografa cada mensagem individualmente com o uso de uma chave

59/72 derivada. A troca de mensagens 652, então, segmenta cada mensagem e encapsula os segmentos. Na etapa 610, a troca de mensagens 652 envia os segmentos encapsulados à fila de ponto de conexão 653. Os segmentos de mensagem são então priorizados e as mensagens no plano de fundo são retidas até o próximo batimento cardíaco. Os cabeçalhos de segmento são criptografados e os segmentos são concatenados juntos. Na etapa 615, os segmentos concatenados são enviados à pilha de TCP/IP do OS 660. A partir dela, os segmentos são enviados para a rede 670 na etapa 620 e para o GHC conectado para roteamento.

[121] A Publicação/assinatura (Pub/Sub) é um contrato de serviço administrado no ponto de conexão no bloco de motor clínico integrado e é, portanto, compartilhado por todos os aplicativos. O ponto de conexão administra o rastreamento de listas de assinante e expande a mensagem de publicação com uma lista de extremidades de assinante. O ponto de conexão envia os segmentos de mensagem apenas uma vez para um GHC com a lista de assinante. O GHC, então, bifurca os segmentos conforme necessário para alcançar todos os assinantes. Esse roteamento de segmentos de mensagem minimiza o tráfego de rede e a drenagem da batería no publicador. Quando necessário, o assinante precisa reestabelecer assinaturas à medida que o publicador não renova assinaturas. O assinante deve reassinar se o publicador desaparecer para evitar assinaturas abandonadas.

[122] O diretório da troca de mensagens é um banco de dados em memória mantido por cada GHC e é reforçado por SQLite para expandir até um nível de milhões de inscrições. Em uma modalidade, o diretório é replicado através de todos

60/72 os GHCs em um domínio contido em 2 a 5 segundos. 0 ativador de replicação (sinalizador sujo) é sobreposto em um batimento cardíaco. Em uma modalidade, o diretório inclui um relatório de todos os dispositivos, extremidades, e serviços e também mantém as localizações de dispositivo. A determinação de uma localização de dispositivo pode proporcionar assistência a um cuidador para que encontre um paciente. Em uma modalidade, a última localização conhecida também é renovada para o catálogo de ativos quando um dispositivo for esvaziado. O diretório também é extensível para descoberta de dispositivo de terceiros.

[123] Em uma modalidade, a maioria das mensagens enviadas por meio da troca é enviada como código de fonte Lua. O uso de Lua é seguro à medida que é mantido controle sobre a rede e o aplicativo de portal. A codificação de fonte Lua fornece decodificação de mensagem simples. Por exemplo, em uma modalidade, um usuário pode usar o método loadString() no conteúdo da mensagem para obter valores. Além disso, a codificação de fonte Lua possibilita um sistema mais rápido, à medida que o analisador de Lua é otimizado para conjuntos de dados (>300/seg. em um computador do tipo tablet) . O uso de código de fonte Lua muda o paradigma de contratos de serviço de mensagem através da eliminação de mensagens de formato rígido fixo e baseando-se o contrato no efeito da mensagem mediante confirmação e execução. As confirmações de retorno para mensagens são geradas através da adição de código na mensagem.

DADOS DE CLÍNICOS E DE SESSÕES DE PACIENTE [124] No sistema de informações de dados médicos do

61/72 presente relatório descritivo, uma sessão de paciente é um ambiente para todos os dados clínicos reunidos do paciente. Cada sessão é criada pelo dispositivo de obtenção de sistema quando coletar dados de paciente. Além disso, cada sessão é identificada por dispositivo através de um identificador globalmente único (GUID). As sessões são cumulativamente imutáveis à medida que podem apenas ser anexadas. Em uma modalidade, cada sessão é dividida em tiras de uma hora para evitar sessões oscilantes. As sessões em si são anônimas, sem informações de saúde protegidas (PHI). Os dados em cada sessão são definitivos, incluindo todos os dados, e podem ser reproduzidos de forma semelhante ao conteúdo de um gravador de vídeo digital. Além disso, em uma modalidade, cada sessão inclui todos os dados clínicos e alarmes, mudanças de definições, e um relatório de quem fez as mudanças.

[125] Em uma modalidade, as sessões originaram nos dispositivos de obtenção de sistema e são armazenadas e distribuídas nos GHCs. Os GHCs coletam todas as tiras de sessão com o uso de um protocolo de replicação. 0 atraso na replicação é de tipicamente apenas alguns segundos de modo que os dados retrospectivos estejam disponíveis rapidamente para análise. Em uma modalidade, os GHCs de nuvem coletam apenas tiras de sessão sob demanda.

[126] A associação de paciente com uma sessão é separada de uma duração de sessão. Uma nova sessão pode ser criada para um paciente sem ter que admitir e a associação pode ser feita no começo, durante, ou depois da sessão. Os farelos de pão, como notas de voz, ajudam com a associação de sessão. Em uma modalidade, as anotações

62/72 contra um intervalo de tempo são mantidas no relatório do paciente. Em uma modalidade, as anotações podem ser manuais ou sintéticas (por exemplo, criadas a partir de alarmes). Em termos de arquivamento e armazenamento de sessão, em uma modalidade, após um período de retenção básico, uma sessão pode ser aparada. Em uma modalidade, aparar uma sessão envolve descartar dados de forma de onda não alarmados e não anotados. Uma sessão aparada é migrada para a nuvem e descartada a partir dos GHCs. Movendo-se as sessões aparadas para a nuvem, o sistema fornece armazenamento essencialmente infinito dependendo de quanto tempo o cliente decide pagar pelo armazenamento.

ROTEAMENTO DE ALARME E SUPRESSÃO DE ALARME [127] Em uma modalidade, o sistema para fornecer cuidados de paciente do presente relatório descritivo um método de prioridade de roteamento de alarme com base nas informações de localização e presença tanto do paciente quanto dos cuidadores. Em uma modalidade, o método de prioridade de roteamento de alarme é similar àquele revelado no Pedido de Patente n- U.S. 13/300.434, intitulado System and Method for Transfer of Primary Alarm Notification on Pacient Monitoring Systems, depositado em 18 de novembro de 2011 e cedido ao requerente da presente invenção, que é incorporado ao presente documento a título de referência em sua totalidade.

[128] Em uma modalidade, o sistema do presente relatório descritivo irá rotear alarmes primários ao responder disponível mais próximo, assim, minimizando o tempo levado entre o alarme e a resposta a partir do cuidador. Em uma modalidade exemplificativa, um primeiro

63/72 cuidador é designado como um operador responsável para um paciente (é diretamente responsável pelo dito paciente). 0 primeiro cuidador atribui o seu dispositivo de visor de alarme móvel para receber os alarmes para o paciente. Um alarme crucial para o paciente anuncia no dispositivo móvel. 0 primeiro cuidador olha para o visor no dispositivo móvel e determina que o paciente ainda está no leito que um segundo cuidador (operador) já está ao lado do leito do paciente. 0 primeiro cuidador pressionar o nome do segundo cuidador no visor do dispositivo móvel e é colocado imediatamente em comunicação de voz em duas vias com o segundo cuidador a fim de avaliar a situação.

[129] Em outra modalidade exemplificativa, um paciente de telemetria deixa a unidade para caminhar. Quando está fora da unidade, o paciente tem uma parada cardiaca e entra em colapso. Um monitor de telemetria usado pelo paciente emite um alarme de alta prioridade. 0 sistema do presente relatório descritivo, com base no conhecimento da localização fisica do paciente, alerta o operador responsável do paciente na enfermaria geral de telemetria e dois operadores adicionais mais próximos à paciente localização atual do paciente para auxilio. 0 sistema coloca adicionalmente todos os três cuidadores em comunicação por meio de seus dispositivos móveis até que a situação seja resolvida.

[130] Em outra modalidade, o sistema inclui um alerta de dispositivo em que alarmes específicos são entregues a dispositivos portáteis portados pelos cuidadores préselecionados. Por exemplo, o sistema pode enviar um alerta a um PDA do médico ou da enfermeira no UTI/UCO. Um grupo de

64/72 cuidadores distribuídos pré-selecionados irá receber o alarme de prioridade. Essa notificação seletiva significa que nem todos na rede recebem o alarme. Por exemplo, caso um cuidador está no quarto 5, então, o sistema pode alvejar alarmes àquele cuidador. A notificação de localização de cuidador pode também ser especificada a um conjunto de habilidades particular. Em uma modalidade, há um despachante mestre que é notificado de todos os alertas para garantir a resposta. Alvejar e atribuir um alerta e atribuir a cuidadores selecionados intensifica a eficiência de resposta do sistema garantindo-se que o cuidador mais apropriado irá receber o primeiro alerta.

[131] Em uma modalidade, o sistema para fornecer cuidados de paciente do presente relatório descritivo também fornece um método orientado por equipe de cuidador e distribuído para gerenciar alarmes. 0 método forneceu silêncios ou supressões de alarmes. Quando uma condição de alarme é detectada por um dispositivo conectado a um paciente, o sistema irá notificar os cuidadores apropriados ao paciente que a condição de alarme está ocorrendo. Qualquer dos operadores que recebe a mensagem de alarme com os direitos apropriados fazê-lo pode suprimir o alarme. A supressão de alarmes por um operador coloca todos os dispositivos que exibem atualmente as informações de alarme em um estado suprimido que pode tanto silenciar o dispositivo como ter o mesmo comportamento como uma operação de conhecimento de alarme tradicional. A operação de supressão indica aos outros operadores que a condição de alarme foi observada e que um operador autorizado está tomando a ação apropriada.

65/72 [132] Em uma modalidade, um estado suprimido por alarmes aplica todos os dispositivos de obtenção associados a um paciente e irá persistir até que um periodo de tempo esgotado expire ou que uma nova condição de alarme com prioridade mais alto que o que foi suprimido seja detectada. Caso ocorra qualquer uma dessas condições de, o estado suprimido por alarmes é limpo e todos os dispositivos de visor de alarme exibem os sinais de alarme completos como apropriados para o presente conjunto de condições de alarme.

[133] Em uma modalidade, a iniciação de uma supressão enquanto já em um estado suprimido por alarme irá reiniciar o tempo esgotado e reiniciar a propriedade suprimida por alarme com base no conjunto de condições de alarme atualmente presentes. Em uma modalidade, qualquer operador tem a habilidade para cancelar um estado suprimido por alarmes e retornar todos os dispositivos de visor de alarme para completa funcionalidade de alarme.

RECURSOS OPCIONAIS [134] Em várias modalidades, o sistema para fornecer cuidados de paciente do presente relatório descritivo inclui adicionalmente qualquer recurso ou combinação dos recursos opcionais a seguir.

[135] Em uma modalidade, os dispositivos de visor do sistema têm a capacidade para fornecer exibição logaritmica de formas de onda. Através da compressão de maneira logaritmica da escala de tempo nas bordas distantes à direita e à esquerda em um visor de forma de onda, o sistema aponta ao usuário que dados adicionais estão disponíveis. Um cuidador pode passar nessas áreas para

66/72 mover os dados para se concentrar na parte central da forma de onda. Um cuidador pode também comutar uma visualização dos dados linear após localizar uma seção da forma de onda que o cuidador gostaria de revisar mais detalhadamente.

[136] Em uma modalidade, os dispositivos de sistema incluem alarmes de voz além dos nos de alarme do tipo tinido. Por exemplo, sintese de voz adicionada em um fone usado pelos cuidadores fornece detalhes de alarme adicionais incluindo causa de alarme, localização de paciente (por exemplo, quarto, cirúrgica, etc.) e o nome do paciente.

[137] Em uma modalidade, os dispositivos de sistema fornecem regimes de paciente ambulatório para pacientes mediante descarga ou para paciente ambulatório. Quando pacientes levam um dispositivo de monitoramento para casa para o paciente ambulatório, o dispositivo tem capacidade para fornecer auxilio adicional para cuidados incluindo instruções legíveis para paciente ambulatório aos quais, tradicionalmente, é dado oralmente na alta hospitalar, regimes de medicamentos, incluindo lembretes de calendários embutidos, a habilidade para varrer códigos de resposta rápida (QR) em medicamento de prescrição para verificar regimes de medicamento e outras tarefas semelhantes.

[138] Em uma modalidade, códigos de QR são usados para auxiliar nos serviços de localização. Além de tecnologias avançadas como triangulação de Wi-Fi e comunicação de campo de proximidade (NFC), simplesmente a impressão e, em seguida, a colagem de códigos de QR em portas fornece um uma consciência de um método de localização não dispendioso que é particularmente aplicável a mercados emergentes. As

67/72 câmeras nos dispositivos de cuidador são usadas para ajustar o código e fornecem a consciência de localização.

[139] Em uma modalidade, o sistema inclui visores inteligentes em paredes para fornecer tanto as informações de paciente quanto entretenimento para pacientes e famílias. Os dispositivos de visor em um quarto de paciente atuam como hubs de entretenimento quando os cuidadores não estão presentes, porém comutam automaticamente para fornecer informações de cuidados de paciente assim que um cuidador entre no quarto. Em uma modalidade, o sistema fornece uma configuração de visor dupla conforme descrito no Pedido de Patente n- U.S. 13/052.883, intitulado MultiDisplay Bedside Monitoring System, depositado em 21 de março de 2011 e cedido ao requerente da presente invenção, que é incorporado ao presente documento em sua totalidade.

[140] O sistema fornece um monitor de exibição duplo que pode ser ajustado em uma cabeceira de paciente para fornecer informações agregadas relacionadas ao paciente ao longo das estatísticas vitais de paciente em tempo real. Um dentre os visores mostram continuamente mostra as informações de paciente em tempo rela, enquanto que o outro é usado para exibir informações como quando medicamentos foram entregues, resultados de laboratório lentos em referência a sinais vitais e fornece acesso a outras aplicativos hospitalares remotos, tipicamente, acessíveis apenas por meio de terminais de dados separados. O monitor de exibição duplo é conectado ao sistema de informações e de hospital e tem capacidade para exibir os aplicativos de software locais e aplicativos de software remotos por meio do software de visor remoto, como, o software

68/72 disponibilizado por Citrix™. Além disso, o monitor de exibição duplo pode ser conectado a uma configuração de monitor central que pode incluir até quatro visores adicionais. Esses visores adicionais podem ser usados para monitorar mais pacientes, dados adicionais de visor e/ou hospedeiros e outras aplicações.

[141] Adicionalmente, em modalidades adicionais, os aplicativos de software locais e remotos acessados no monitor de exibição duplo também compreendem aplicações além daquelas recém-relacionadas para fornecer funcionalidade de monitoramento de paciente. Por exemplo, tal software pode ser um aplicativo de entretenimento; de internet ou qualquer outro aplicativo de conectividade de rede; ou um aplicativo de educação de paciente ou um aplicativo de conferência de e-mail ou vídeo ou qualquer outro aplicativo com valor adicionado que estaria vantajosamente evidente àqueles de habilidade comum na técnica.

[142] Em uma modalidade, o monitor de exibição duplo pode ser habilitado tanto no modo paciente como no modo cuidador. No modo paciente, os ajustes clínicos não podem ser mudados, porém uma lista controlada de aplicativos de software aprovados, como entretenimento ou educação de paciente, podem ser executadas. 0 monitor está em modo paciente a menos que um cuidador esteja no quarto. Assim, por exemplo, quando o paciente está no quarto não atendido, o monitor estaria tipicamente no modo paciente. 0 modo pode ser mudado remotamente por um cuidador. Para mudar para um modo cuidador, o monitor é habilitado para tomar uma credencial, senha ou um selo de RFID. Em uma modalidade, é

69/72 possível a desabilitação ou a minimização sensível ao contexto ou de modo paciente. Assim, caso ocorra uma mudança no estado clínico [por exemplo, uma determinada classe de alarme (prioridade alta)], o aplicativo do paciente é desabilitado ou minimizado até que seja limpo por um cuidador. Idealmente, isso seria configurável pelo cuidador pelo tipo de alarme ou classe de alarme.

[143] Em uma modalidade, o sistema fornece uma cascata de algoritmo do tipo ligue e use que intensifica e dinamiza o agrupamento de dados dentre os dispositivos. Quando um sensor é conectado a um dispositivo, dispara um carregamento do aplicativo de driver apropriado. Esse driver, por sua vez, publica os dados clínicos do dispositivo. Esses dados são moldados como um sensor virtual que faz com que outro aplicativo de driver carregue e processe os dados, assim, causando uma cascata de cargas de driver, conforme necessário. Isso permite que drivers de alarme inteligentes carreguem e agrupem dados a partir de múltiplos dispositivos.

[144] Em uma modalidade, o sistema possibilita o fluxo de dados médicos em cascata automontante descrevendo-se o algoritmo de dados médicos como um bloco funcional com entradas e saídas definidas. Quando uma saída particular é desejada, o conjunto de blocos pode automontar com o uso dos metadados para conectar as entradas e as saídas em um uma cascata reversa (fornecida pelo consumidor). Isso é aplicável tanto para os dados em tempo real quanto para a análise retrospectiva. Além disso, o conjunto de saídas disponíveis é facilmente computado a partir das saídas cruas disponíveis e das permutações de algoritmos.

70/72 [145] Em uma modalidade, um dispositivo de sistema pode realizar um autoteste para determinar se tem capacidade para atuar como um dispositivo de exibição de alarme. Em várias modalidades, nem todos os dispositivos de sistema terão capacidade para atuar como um dispositivo de exibição de alarme. As limitações podem estar na capacidade dos dispositivos para gerar tons audiveis altos o suficiente ou para exibir visualmente mensagens grandes o suficiente para satisfazer as exigências de capacidade de uso. Um autoteste é realizado por um aplicativo instalado no dispositivo e os resultados são usados pelo sistema para determinar se o dispositivo tem capacidade para atuar como um dispositivo de exibição de alarme.

[146] Em uma modalidade, o sistema fornece um meio para agregar e para armazenar os dados do paciente em um único arquivo para que o mesmo possa ser acessado por qualquer cuidador a qualquer momento durante a estada do paciente no hospital. Em uma modalidade, o meio inclui um único dispositivo com base em PC com capacidade para exibir dados para até 64 pacientes em uma visualização remota em tempo real. O dispositivo pode também ser acoplado a quatro dispositivos adicionais para aprimorar a visualização.

[147] O dispositivo inclui uma interface de usuário robusta para apresentar os dados de paciente retrospectivamente. O dispositivo funciona como uma estação remota centralizada para visualizar todos os dados do paciente como se os dados estivessem integrados ao dispositivo. Os cuidadores podem visualizar os dados clinicos a partir de qualquer localização e a qualquer momento.

71/72 [148] Além disso, em uma modalidade, o dispositivo possibilita a associação e a identificação de paciente sob a forma de um gerenciador de registro de um paciente e de um rastreador de sessão. Com os sistemas de monitoramento de paciente convencionais, o armazenamento de dados é centralizado no dispositivo, em que de ser centralizado no paciente. Como tal, os dados de paciente podem anda residir no dispositivo no quarto, mesmo após ter sido dada a alta ao paciente. Além disso, com sistemas convencionais, os números de registro médico (MR) e números de identificação podem ser confundidos. Incorporando-se um gerenciador de registro de paciente e um rastreador de sessão, uma nova sessão é iniciada para passar pela reassociação quando o fluxo de dados para. Cada paciente é associado a um número de série eletrônico. Portanto, quando um paciente é desconectado a partir de um dispositivo de monitoramento e reconectado a outro dispositivo de monitoramento, o paciente é reassociado ao novo dispositivo. Em uma modalidade, as sessões podem ser incorporadas para que todos os dados de paciente a partir dos vários dispositivos possam ser visualizados no total.

[149] Os pacientes podem ser associados a diferentes dispositivos de monitoramento por meio inúmeros métodos de associação. Em várias modalidades, os mesmos incluem varredura retinal automática, identificação biométrica de paciente e identificação com base em sensor. Por exemplo, a associação pode ser realizada coletando-se e analisando-se uma amostra de DNA, analisando-se uma impressão digital, ou através de outro procedimento não invasivo. Cada método de associação identifica o paciente e coordena o dispositivo e

72/72 os registros de dados a partir do dispositivo com aquele paciente. Uma vez estabelecido, uma associação entre um dispositivo especifico e um único paciente está sempre presente e nunca há nenhum problema em estabelecer uma associação duplicada. Isso também evita o problema perder uma associação dispositivo-paciente que ocorre quando um bracelete de RFID é quebrado.

[150] Em outra modalidade, cada paciente é associado a um dispositivo por uma etiqueta ou cordão de segurança que é passado entre os cuidadores e precisariam ser notificados em qualquer tempo dado durante o cuidado do paciente.

[151] Em uma modalidade, o sistema também possibilita a associação entre um dispositivo de cuidador e dados de paciente. Cada cuidador pode personalizar o visor no dispositivo portátil com base no que aquela pessoa quer. Os exemplos acima são meramente ilustrativos das muitas aplicações do sistema da presente invenção. Embora apenas algumas modalidades da presente invenção tenham sido descritas no presente documento, deve-se entender que a presente invenção pode ser incorporada em muitas outras formas especificas sem se afastar do espirito ou do ou escopo da invenção. Portanto, os presentes exemplos e modalidades devem ser considerados como ilustrativos e não restritivos, e a invenção pode ser modificada dentro do escopo das reivindicações anexas.

Claims (7)

1) recebe a dita mensagem a partir do dito segundo dispositivo de computação;

1) recebe a dita mensagem a partir do dito primeiro dispositivo de computação;

1. criptografa, com o uso de uma linguagem de script-padrão, um programa executável e anexa o dito programa criptografado ao cabeçalho de uma mensagem; e

1. Sistema para fornecer cuidados de paciente caracterizado pelo fato de que compreende:

a. um primeiro dispositivo de computação que tem um primeiro meio legivel por computador volátil ou não volátil, sem incluir meios de transmissão para transmitir ondas, em que o dito primeiro meio compreende:

i. uma primeira pluralidade de instruções programáticas, em que, quando executadas pelo dito primeiro dispositivo de computação, a dita primeira pluralidade de instruções programáticas:

2. Sistema para fornecer cuidados de paciente caracterizado pelo fato de que compreende:

a. pelo menos um dispositivo de captação configurado para detectar e relatar pelo menos um parâmetro fisiológico de um paciente;

b. pelo menos um dispositivo de obtenção acoplado ao dito pelo menos um dispositivo de captação, em que o dito dispositivo de obtenção recebe dados de paciente eletrônicos a partir do dito pelo menos um dispositivo de captação e inclui memória com capacidade de armazenar os ditos dados de paciente;

2) descriptografa o dito programa executável; e

2/7

2) determina, a partir da dita mensagem, pelo menos um dispositivo de computação-alvo destinado a receber a dita mensagem; e

2. transmite a dita mensagem a partir do primeiro dispositivo de computação para um segundo dispositivo de computação por meio de uma conexão sem fio;

b. um segundo dispositivo de computação que tem um segundo meio legivel por computador volátil ou não volátil, sem incluir meios de transmissão para transmitir ondas, em que o dito segundo meio compreende:

i. uma segunda pluralidade de instruções programáticas, em que, quando executadas pelo segundo dispositivo de computação, a dita segunda pluralidade de instruções programáticas:

3/7

c. pelo menos um aparelho de rede acoplado ao dito pelo menos um dispositivo de obtenção em que o dito aparelho de rede é configurado para receber os ditos dados de paciente a partir do dito dispositivo de obtenção;

d. uma rede para fornecer computação em nuvem em que o dito pelo menos um aparelho de rede é acoplado à dita rede e em que a dita rede inclui um banco de dados para armazenar os ditos dados de paciente de modo que os ditos dados de paciente sejam acessíveis através de todos os dispositivos de rede; e

e. pelo menos um dispositivo de apresentação acoplado à dita rede, em que o dito dispositivo de apresentação é configurado para acessar os ditos dados de paciente e exibir os ditos dados de paciente em uma interface de usuário gráfica;

em que a transmissão dos ditos dados de paciente eletrônicos através da dita rede inclui criptografar os ditos dados de paciente através da codificação de um programa executável com o uso de uma linguagem de script-

padrão e anexação do dito programa a uma mensagem que inclui os ditos dados de paciente. 3. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de

que o dito aparelho de rede é situado próximo ao paciente.

3) executa o dito programa executável e, dessa forma, recebe a dita mensagem;

em que o dito segundo dispositivo de computação é um dispositivo de computação com base em nuvem.

3) transmite a dita mensagem a partir do dito segundo dispositivo de computação para o dito pelo menos um dispositivo de computação-alvo por meio de uma conexão sem fio; e

c. pelo menos um dispositivo de computação-alvo que tem um terceiro meio legível por computador volátil ou não volátil, sem incluir meios de transmissão para transmitir ondas, em que o dito terceiro meio compreende:

i. uma terceira pluralidade de instruções programáticas, em que, quando executadas pelo terceiro dispositivo de computação, a dita terceira pluralidade de instruções programáticas:

4/Ί ao dito pelo menos um dispositivo de obtenção por meio de uma conexão com fio.

4. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que o dito aparelho de rede é situado distante do paciente.

5/7 sistema .

12. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que o dito dispositivo de obtenção é um dispositivo fixo nas instalações do cuidador.

13. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que o dito dispositivo de obtenção é um dispositivo móvel que permanece com o dito paciente mediante descarga e para paciente ambulatorial.

14. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que inclui adicionalmente um algoritmo de roteamento com base em custos que calcula a rota de mensagem mais eficaz através da medição direta do desempenho de rede atual durante o uso real.

15. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que inclui adicionalmente um protocolo de roteamento de alarme que gera rota de prioridade de alarme com base nas informações de localização e presença tanto do dito paciente quanto de um cuidador.

16. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que um cuidador pode silenciar ou reduzir o volume de um alarme audível para todos os dispositivos atribuídos ao dito paciente. 17 . Sistema para fornecer cuidados de paciente, de

acordo com a reivindicação 2, caracterizado pelo fato de que inclui adicionalmente uma troca de mensagens central

5. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que o dito pelo menos um dispositivo de captação é acoplado

6/Ί confiável que estabelece uma ligação criptografada uma vez por dispositivo entre a troca e cada transmissor e receptor de mensagem.

18. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 17, caracterizado pelo fato de que a dita troca de mensagens central acumula mensagens não urgentes que devem ser enviadas periodicamente.

19. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 17, caracterizado pelo fato de que o dito transmissor de mensagem é configurado para enviar cada mensagem apenas uma vez e a dita troca de mensagens central é configurada para duplicar e enviar cada mensagem a múltiplos recipientes com base em uma lista de assinaturas incluída em um cabeçalho da dita mensagem.

20. Método para fornecer cuidados de paciente caracterizado pelo fato de que compreende as seguintes etapas:

a. fornecer um sistema de cuidados de paciente que compreende:

i. pelo menos um dispositivo de captação configurado para detectar e relatar pelo menos um parâmetro fisiológico de um paciente;

ii. pelo menos um dispositivo de obtenção acoplado ao dito pelo menos um dispositivo de captação, sendo que o dito dispositivo de obtenção recebe dados de paciente eletrônicos a partir do dito pelo menos um dispositivo de captação e inclui memória com capacidade de armazenar os ditos dados de paciente;

iii. pelo menos um aparelho de rede acoplado ao dito pelo menos um dispositivo de obtenção, sendo que o

6. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que o dito pelo menos um dispositivo de captação é acoplado ao dito pelo menos um dispositivo de obtenção por meio de uma conexão sem fio.

7. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que o dito pelo menos um dispositivo de captação e o dito pelo menos um dispositivo de obtenção podem ser conectados à rede por meio de uma conexão de 3G/4G.

8. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que a dita uma linguagem de script-padrão é Lua.

9. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que o dito dispositivo de apresentação compreende qualquer um dentre um PC tradicional, computador do tipo tablet, telefone inteligente (smartphone), ou visor montado em parede.

10. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que o dito dispositivo de obtenção também funciona como um dispositivo de apresentação.

11. Sistema para fornecer cuidados de paciente, de acordo com a reivindicação 2, caracterizado pelo fato de que o dito dispositivo de obtenção duplica e armazena todos os dados clínicos para o dito paciente na dita memória e funciona como um monitor autônomo no caso de falha de

7/7 dito aparelho de rede é configurado para receber os ditos dados de paciente a partir do dito dispositivo de obtenção;

iv. uma rede para fornecer computação em nuvem, sendo que o dito pelo menos um aparelho de rede é acoplado à dita rede, e em que a dita rede inclui um banco de dados para armazenar os ditos dados de paciente de modo que os ditos dados de paciente sejam acessíveis através de todos os dispositivos de rede; e

v. pelo menos um dispositivo de apresentação acoplado à dita rede, sendo que o dito dispositivo de apresentação é configurado para acessar os ditos dados de paciente e exibir os ditos dados de paciente em uma interface de usuário gráfica;

b. detectar e relatar o dito pelo menos um parâmetro fisiológico de paciente com o uso do dito pelo menos um dispositivo de captação;

c. transmitir dados eletrônicos representativos do dito pelo menos um parâmetro fisiológico ao dito dispositivo de obtenção;

d. criptografar os ditos dados de paciente através da codificação de um programa executável com o uso de uma linguagem de script-padrão e anexar o dito programa a uma mensagem que inclui os ditos dados de paciente;

e. transmitir os ditos dados criptografados ao dito aparelho de rede;

f. armazenar os ditos dados na dita rede com o uso de computação em nuvem;

g. acessar, descriptografar e exibir os ditos dados com o uso do dito dispositivo de apresentação.