BR112018002822B1

BR112018002822B1 - Sistema de tratamento de saúde em rede

Info

Publication number: BR112018002822B1
Application number: BR112018002822-3A
Authority: BR
Inventors: Jonathan Alan Handler
Original assignee: Baxter International Inc.; Baxter Healthcare S.A
Priority date: 2015-08-14
Filing date: 2016-08-12
Publication date: 2022-09-20
Also published as: GB2603250A; AU2016308443A1; JP2022133315A; US20190001059A1; AU2021209191A1; GB2603250B; CA2995463A1; JP2020006193A; CN108025132B; JP7092725B2; MX2018001866A; EP3334481A1; US11738145B2; GB2559279A; US20170043089A1; CN114010874B; US20210001045A1; US20230405223A1; BR112018002822A2; US10780224B2

Abstract

MÉTODOS E APARELHOS PARA INTEGRAÇÃO DE DADOS DE DISPOSITIVO MÉDICO. Métodos, sistemas e aparelhos de integração de dados de dispositivo médico são divulgados. Em uma modalidade de exemplo, um aparelho de monitor de sinais vitais inclui uma interface de terapia de insuficiência renal configurada para receber um parâmetro de terapia de insuficiência renal a partir de uma máquina de terapia de insuficiência renal que realiza um tratamento de terapia de insuficiência renal em um paciente e uma interface de bomba de infusão configurada para receber um parâmetro de infusão a partir de uma bomba de infusão que realiza um tratamento de infusão para o mesmo paciente. O aparelho também inclui um motor de monitor de sinais vitais configurado para exibir, em uma combinação de interface de usuário de um monitor de sinais vitais, o parâmetro de terapia de insuficiência renal com uma linha de tempo de terapia de insuficiência renal, e um parâmetro de infusão com um linha de tempo de infusão que é alinhado com a linha de tempo de terapia de falha renal.

Description

Campo técnico

[0001] A presente descrição refere-se, em geral, a integração de dados de dispositivo médico, e mais especificamente, a integração de dados de bomba de infusão e dados de terapia de insuficiência renal para a exibição em uma interface de usuário único.

Antecedentes

[0002] Hospitais utilizam diferentes tipos de dispositivos médicos de diferentes fabricantes. Ao mesmo tempo que os dispositivos médicos são configurados para se comunicarem através de uma mesma rede (por exemplo, uma rede de área local (“LAN”)), o formato dos dados provenientes de cada dispositivo é diferente. Cada desenvolvedor de dispositivo médico pode ter o seu próprio formato proprietário que ele acredita ser melhor do que os outros formatos. Os desenvolvedores de dispositivos tentam alcançar um uso em grande escala de seus formatos de dados proprietários para restringir a entrada de outros desenvolvedores no sistema hospitalar ou para obter pagamentos de licenças provenientes de outros desenvolvedores que também desejem utilizar o mesmo formato de dados. Mesmo os desenvolvedores que utilizam um formato de dados padrão, tal como o Health Level 7 (“HL7”), podem ainda fazer uso de campos de dados customizados e definições para dificultar que outros desenvolvedores integrem seus dispositivos médicos no mesmo sistema.

[0003] Em um exemplo, um sistema hospitalar pode selecionar a utilização de bombas de infusão provenientes de um primeiro desenvolvedor. Os dados provenientes da bomba de infusão são formatados com a utilização de um formato proprietário. A utilização do formato proprietário força o hospital a gastar milhões de dólares e meses de tempo para desenvolver uma interface que torne os dados provenientes das bombas de infusão compatíveis com o resto do sistema. Uma interface pode, por exemplo, converter os dados da bomba de infusão em um formato capaz de ser incluído nos registros médicos eletrônicos ou em transmissão para dispositivos de interface de usuários, tal como um sistema de monitoramento centralizado ou smartphones/computadores tablets clínicos. A interface pode também converter os dados originários do sistema hospitalar em um formato que seja compatível com a bomba de infusão. Por exemplo, uma prescrição de terapia de infusão eletrônica proveniente de um sistema de gerenciamento de farmácia pode ser convertida em um formato que é reconhecido por uma bomba de infusão.

[0004] Como pode ser apreciado, a utilização de formatos de dados proprietários e interfaces especializadas torna difícil ou quase impossível que dispositivos médicos compartilhem ou integrem dados. Isto poderia exigir, por exemplo, que os desenvolvedores de dispositivos médicos criassem interfaces separadas para seus dispositivos que fossem compatíveis com todos os formatos de dados proprietários possíveis. Como alternativa, o sistema hospitalar teria de criar interfaces especializadas adicionais. Dado o número de diferentes tipos de dispositivos médicos (por exemplo, bombas de infusão, máquinas de terapia renal ou diálise, monitores de sinal vital / sensores fisiológicos, scanners médicos, etc.), esta é uma tarefa quase impossível.

Sumário

[0005] Um aparelho, método e sistema de exemplo são divulgados neste documento, que simultaneamente exibem dados provenientes de diferentes tipos de dispositivos médicos em uma interface de usuário ou monitor único. O aparelho, método e sistema de exemplo são configurados com um motor de integração que é especialmente programado para converter os dados provenientes de vários dispositivos médicos para um protocolo ou formato comum. A conversão dos dados provenientes de vários dispositivos para um formato possibilita que os dados sejam exibidos simultaneamente em uma interface de usuário única. A conversão dos dados provenientes de vários dispositivos para um formato também possibilita que cálculos ou rotinas sejam executados para determinar o relacionamento entre os diferentes tipos de dados. Por exemplo, dados de infusão, dados de terapia de insuficiência renal, e dados de coleta de urina podem ser analisados em conjunto para determinar um equilíbrio de fluidos do paciente. Em outros exemplos, os diferentes tipos de dados podem ser analizados coletivamente para determinar tendências que talvez não sejam aparentes ao analizar os dados a partir de um sensor ou dispositivo médico. Além disso, a integração dos dados provenientes de vários dispositivos permite a modificação ou ajuste de certos limites do dispositivo ou limites de alarme.

[0006] Aspectos do assunto descrito neste documento podem ser úteis isolados ou em combinação com um ou mais de outros aspectos descritos neste documento. Sem que se limite a descrição supracitada, em um primeiro aspecto da presente descrição, um sistema de tratamento de saúde em rede compreende uma máquina de terapia de insuficiência renal acoplada de forma comunicativa a um sistema de informação hospitalar configurado para realizar um tratamento de terapia de insuficiência renal para um paciente, determina pelo menos um parâmetro de terapia de insuficiência renal relacionado com o tratamento de terapia de insuficiência renal que inclui uma taxa de ultrafiltragem na qual um fluido é removido do paciente, determina um registro de tempo da terapia de insuficiência renal para o pelo menos um parâmetro de terapia de insuficiência renal, e transmite o pelo menos um parâmetro de terapia de insuficiência renal, um identificador de paciente do paciente, e o registro de tempo da terapia de insuficiência renal para o sistema de informação hospitalar. O sistema também compreende uma bomba de infusão acoplada de forma comunicativa ao sistema de informação hospitalar configurada para realizar o tratamento de infusão para o mesmo paciente simultaneamente com a máquina de terapia de insuficiência renal, determinar pelo menos um parâmetro de infusão relacionado com o tratamento de infusão que inclui uma taxa de infusão na qual um fluido é injetado no paciente, determinar um registro de tempo de infusão para o pelo menos um parâmetro de infusão, e transmitir o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo de infusão para o sistema de informação hospitalar. O sistema ainda compreende um monitor de sinais vitais associado ao paciente acoplado de forma comunicativa ao sistema de informação hospitalar, e funcionando em conjunto com um motor de integração, configurado para receber o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal, receber o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo da infusão, determinar o pelo menos um parâmetro de terapia de insuficiência renal e o pelo menos um parâmetro de infusão que devem ser exibidos em uma combinação de interface de usuário baseada no identificador do paciente, determinar um parâmetro de diferença com base em uma diferença entre o pelo menos um parâmetro de infusão e o pelo menos um parâmetro de terapia de insuficiência renal, exibir, na combinação de interface de usuário, o pelo menos um parâmetro de terapia de insuficiência renal com uma linha de tempo da terapia de insuficiência renal, exibir, na combinação de interface de usuário, o pelo menos um parâmetro de infusão com uma linha de tempo de infusão que é alinhado de forma temporal em paralelo com a linha de tempo da terapia de insuficiência renal, e exibir, na combinação de interface de usuário, o parâmetro de diferença com uma linha de tempo de diferença que é alinhado de forma temporal em paralelo com a linha de tempo da terapia de insuficiência renal e com a linha de tempo de infusão.

[0007] Em concordância com um segundo aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser que afirmado de modo contrário, o sistema de tratamento de saúde em rede ainda compreende um motor de porta de monitor configurado para receber o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal proveniente da máquina de terapia de insuficiência renal, receber o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo da infusão proveniente da bomba de infusão, determinar o monitor de sinais vitais dentre uma pluralidade de monitores de sinais vitais que está associado com o identificador do paciente, transmitir o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal para o monitor de sinais vitais determinado, e transmitir o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo de infusão para o monitor de sinais vitais determinados.

[0008] De acordo com um terceiro aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser que afirmado de modo contrário, o sistema de tratamento de saúde em rede ainda compreende um motor de porta de terapia de insuficiência renal configurado para receber o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal proveniente da máquina de terapia de insuficiência renal, determinar o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal que devem ser transmitidos para o motor de porta do monitor, e transmitir o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal para o motor de porta do monitor.

[0009] De acordo com um quarto aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser que afirmado de modo contrário, o sistema de tratamento de saúde em rede ainda compreende um motor de porta de infusão configurado para receber o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo da infusão proveniente da bomba de infusão, determinar o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo da infusão que devem ser transmitidos para o motor de porta de infusão, e transmitir o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo da infusão para o motor de porta do monitor.

[0010] De acordo com um quinto aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser quando afirmado de modo contrário, o monitor de sinais vitais é acoplado de forma comunicativa com um sensor fisiológico e é configurado para receber pelo menos um parâmetro fisiológico a partir do sensor fisiológico e exibir, na combinação de interface de usuário, o pelo menos um parâmetro fisiológico com uma linha de tempo fisiológico que é alinhado de forma temporal em paralelo com a linha de tempo de terapia de insuficiência renal e com a linha de tempo de infusão.

[0011] De acordo com um sexto aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser quando afirmado de modo contrário, o monitor de sinais vitais é configurado para transmitir o pelo menos um parâmetro fisiológico para a pelo menos uma máquina de terapia de insuficiência renal ou para a bomba de infusão por meio do motor de porta do monitor.

[0012] De acordo com um sétimo aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser quando afirmado de modo contrário, o monitor de sinais vitais é configurado para exibir o pelo menos um parâmetro de terapia de insuficiência renal, o pelo menos um parâmetro de infusão, e o parâmetro de diferença como um valor numérico adjacente à linha de tempo respectivo.

[0013] De acordo com um oitavo aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser quando afirmado de modo contrário, a bomba de infusão é uma primeira bomba de infusão e o sistema de tratamento de saúde em rede ainda compreende uma segunda bomba de infusão acoplada de forma comunicativa ao sistema de informação hospitalar, configurada para realizar um segundo tratamento de infusão para o mesmo paciente simultaneamente com a primeira bomba de infusão, determinar o pelo menos um segundo parâmetro de infusão relacionado com o segundo tratamento de infusão, que inclui uma segunda taxa de infusão na qual um segundo fluido é injetado no paciente, determinar um segundo registro de tempo de infusão para o pelo menos um segundo parâmetro de infusão, e transmitir o pelo menos um segundo parâmetro de infusão, o identificador do paciente, e o segundo registro de tempo de infusão ao sistema de informação hospitalar, em que o monitor de sinais vitais funcionando em conjunto com o motor de integração é configurado para receber o pelo menos um segundo parâmetro de infusão, o identificador do paciente, e o segundo registro de tempo de infusão, determinar o parâmetro de diferença com base em uma diferença entre o pelo menos um parâmetro de infusão, o pelo menos um segundo parâmetro de infusão, e o pelo menos um parâmetro de terapia de insuficiência renal, determinar se mais de um tratamento de infusão está sendo fornecido ao paciente, exibir, na combinação de interface de usuário, o pelo menos um segundo parâmetro de infusão com uma segunda linha de tempo de infusão que é alinhado de forma temporal em paralelo com a linha de tempo de infusão, e exibir, na combinação de interface de usuário, um primeiro nome do fluido injetado pela primeira bomba de infusão adjacente à linha de tempo de infusão e um segundo nome do segundo fluido injetado pela segunda bomba de infusão adjacente ao segundo linha de tempo de infusão.

[0014] De acordo com um nono aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser quando afirmado de modo contrário, o pelo menos um parâmetro de diferença inclui uma quantidade líquida de troca de fluido no paciente por um período de tempo.

[0015] De acordo com um décimo aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser quando afirmado de modo contrário, o pelo menos um parâmetro de terapia de insuficiência renal inclui uma taxa na qual o fluido é adicionado ao paciente a partir da máquina de terapia de insuficiência renal, uma quantidade total de fluido removido do paciente, uma quantidade de tempo restante para o tratamento de terapia de insuficiência renal, e um evento associado com o tratamento de terapia de falha renal.

[0016] De acordo com um décimo primeiro aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser quando afirmado de modo contrário, o pelo menos um parâmetro de infusão inclui um registro de tempo, um nome de medicamento do fluido injetado no paciente, uma quantidade total de fluido injetada no paciente, uma quantidade de tempo restante para o tratamento de infusão, um evento associado com o tratamento de infusão, e um limite de medicamento para o tratamento de infusão.

[0017] De acordo com um décimo segundo aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser quando afirmado de modo contrário, um aparelho de monitor de sinais vitais compreende uma interface de terapia de insuficiência renal configurada para receber pelo menos um parâmetro de terapia de insuficiência renal, um identificador do paciente, e um registro de tempo da terapia de insuficiência renal proveniente de uma máquina de terapia de insuficiência renal que executa o tratamento de terapia de insuficiência renal para um paciente associado com o identificador do paciente, uma interface de bomba de infusão configurada para receber pelo menos um parâmetro de infusão, o identificador do paciente, e um registro de tempo de infusão proveniente de uma bomba de infusão que executa um tratamento de infusão para o mesmo paciente, e um motor de monitor de sinais vitais acoplado de forma comunicativa com a interface de terapia de insuficiência renal e com a interface de bomba de infusão, o motor de monitor de sinais vitais configurado para determinar o pelo menos um parâmetro de terapia de insuficiência renal e o pelo menos um parâmetro de infusão que devem ser exibidos na combinação de interface de usuário com base no identificador do paciente, exibir, na combinação de interface de usuário, o pelo menos um parâmetro de terapia de insuficiência renal com uma linha de tempo de terapia de insuficiência renal, e exibir, na combinação de interface de usuário, o pelo menos um parâmetro de infusão com uma linha de tempo de infusão que é alinhado de forma temporal em paralelo com o linha de tempo de terapia de falha renal.

[0018] De acordo com um décimo terceiro aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser quando afirmado de modo contrário, um aparelho de bomba de infusão compreende uma interface de terapia de insuficiência renal configurada para receber pelo menos um parâmetro de terapia de insuficiência renal, um identificador do paciente, e um registro de tempo da terapia de insuficiência renal proveniente de uma máquina de terapia de insuficiência renal que executa um tratamento de terapia de insuficiência renal para um paciente associado com o identificador do paciente, um processador de tratamento de infusão configurado para executar um tratamento de infusão para o mesmo paciente simultaneamente com a máquina de terapia de insuficiência renal, determinar pelo menos um parâmetro de infusão relacionado com o tratamento de infusão que inclui uma taxa de infusão na qual um fluido é injetado no paciente, e determinar um registro de tempo de infusão para o pelo menos um parâmetro de infusão. O aparelho de bomba de infusão também inclui um motor de exibição de infusão configurado para determinar o pelo menos um parâmetro de terapia de insuficiência renal e o pelo menos um parâmetro de infusão que devem ser exibidos na combinação de interface de usuário com base no identificador do paciente, determinar um parâmetro de diferença com base em uma diferença entre o pelo menos um parâmetro de infusão e o pelo menos um parâmetro de terapia de insuficiência renal, exibir, na combinação de interface de usuário, o pelo menos um parâmetro de terapia de insuficiência renal com uma linha de tempo de terapia de insuficiência renal, exibir, com a combinação de interface de usuário, o pelo menos um parâmetro de infusão com uma linha de tempo de infusão que é alinhado de forma temporal em paralelo com o linha de tempo de terapia de insuficiência renal, e exibir, na combinação de interface de usuário, o parâmetro de diferença com uma linha de tempo de diferença que é alinhado de forma temporal em paralelo com o linha de tempo de terapia de insuficiência renal e com a linha de tempo de infusão.

[0019] De acordo com um décimo quarto aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser quando afirmado de modo contrário, um aparelho de máquina de terapia de insuficiência renal compreende uma interface de bomba de infusão configurada para receber pelo menos um parâmetro de infusão, um identificador de paciente, e um registro de tempo de infusão a partir de uma bomba de infusão que realiza um tratamento de infusão para um paciente associado com o identificador do paciente e um processador de tratamento de terapia de insuficiência renal configurado para realizar um tratamento de terapia de insuficiência renal para o mesmo paciente simultaneamente com a máquina de infusão, determinar pelo menos um parâmetro de terapia de insuficiência renal relacionado com o tratamento de terapia de insuficiência renal que inclui uma taxa de ultrafiltragem na qual um fluido é removido do paciente, e determinar um registro de tempo de terapia de insuficiência renal para o pelo menos um parâmetro de infusão. O aparelho de máquina de terapia de insuficiência renal ainda inclui um motor de exibição de terapia de insuficiência renal configurado para determinar o pelo menos um parâmetro de terapia de insuficiência renal e o pelo menos um parâmetro de infusão que devem ser exibidos na combinação de interface de usuário com base no identificador do paciente, determinar o parâmetro de diferença com base em uma diferença entre o pelo menos um parâmetro de infusão e o pelo menos um parâmetro de terapia de insuficiência renal, exibir, na combinação de interface de usuário, o pelo menos um parâmetro de terapia de insuficiência renal com uma linha de tempo de terapia de insuficiência renal, exibir, na combinação de interface de usuário, o pelo menos um parâmetro de infusão com uma linha de tempo de infusão que é alinhado de forma temporal em paralelo com a linha de tempo de terapia de insuficiência renal, e exibir, na combinação de interface de usuário, o parâmetro de diferença com uma linha de tempo de diferença que é alinhado de forma temporal em paralelo com a linha de tempo de terapia de insuficiência renal e com a linha de tempo de infusão.

[0020] De acordo com um décimo quinto aspecto da presente descrição, que pode ser utilizado em combinação com qualquer outro aspecto listado neste documento, a não ser quando afirmado de modo contrário, um aparelho de sistema de monitoramento hospitalar compreende uma interface de bomba de infusão configurada para receber pelo menos um parâmetro de infusão e um identificador de paciente a partir de uma bomba de infusão que realiza um tratamento de infusão para um paciente associado com o identificador do paciente, uma interface de terapia de insuficiência renal configurada paravreceber pelo menos um parâmetro de terapia de insuficiência renal e o identificador do paciente a partir de uma máquina de terapia de insuficiência renal que realiza um tratamento de terapia de insuficiência renal para o mesmo paciente, e uma interface de monitor de sinais vitais configurada para receber pelo menos um parâmetro de sensor fisiológico e o identificador do paciente a partir de um monitor de sinais vitais adjacente para o mesmo paciente. O aparelho de sistema de monitoramento hospitalar também inclui um motor de exibição de sistema de monitoramento configurado para determinar o pelo menos um parâmetro de terapia de insuficiência renal, o pelo menos um parâmetro de infusão, e o pelo menos um parâmetro de sensor fisiológico que devem ser exibidos na combinação de interface de usuário com base no identificador do paciente, determinar um parâmetro de diferença com base em uma diferença entre o pelo menos um parâmetro de infusão e o pelo menos um parâmetro de terapia de insuficiência renal, exibir, na combinação de interface de usuário, a informação relacionada com o pelo menos um parâmetro de terapia de insuficiência renal, exibir, na combinação de interface de usuário, a informação relacionada com o pelo menos um parâmetro de infusão, exibir, na combinação de interface de usuário, a informação relacionada com o pelo menos um parâmetro de diferença, e exibir, na combinação de interface de usuário, a informação relacionada com o pelo menos um parâmetro de sensor fisiológico.

[0021] De acordo com um décimo sexto aspecto da presente descrição, qualquer dentre a estrutura e funcionalidade ilustrada e descrita em conexão com as Figuras 1 a 15 pode ser utilizada em combinação com qualquer dentre a estrutura e funcionalidade ilustrada e descrita em conexão com as Figuras 1 a 15, e com qualquer um ou mais dos aspectos precedentes, a não ser que seja afirmado de modo contrário.

[0022] Características e vantagens adicionais do aparelho, método e sistema divulgados são descritos em, e serão aparentes a partir de, a subsequente Descrição Detalhada e Figuras.

Breve Descrição dos Desenhos

[0023] A Fig. 1 mostra um diagrama de um ambiente de um hospital, de acordo com uma modalidade de exemplo da presente descrição.

[0024] A Fig. 2 mostra um diagrama de uma bomba de infusão exemplar compreendendo a bomba Baxter® SIGMA Spectrum, que pode ser implementada no ambiente de um hospital da Fig. 1, de acordo com uma modalidade de exemplo da presente descrição.

[0025] A Fig. 3 mostra um diagrama de uma máquina de terapia de insuficiência renal ou diálise exemplar compreendendo a máquina Gambro® Prismaflex® CRRT, que pode ser implementada no ambiente de um hospital da Fig. 1, de acordo com uma modalidade de exemplo da presente descrição.

[0026] A Fig. 4 mostra um diagrama de um monitor de um paciente que exibe dados provenientes de um motor de integração no ambiente de um hospital da Fig. 1, de acordo com uma modalidade de exemplo da presente descrição.

[0027] As Figuras 5 a 9 mostram diagramas do ambiente de um hospital da Fig. 1 com o motor de integração funcionando em diferentes dispositivos, de acordo com modalidades de exemplo da presente descrição.

[0028] A Fig. 10 mostra um diagrama do motor de integração de exemplo das Figuras 1 e 5 a 9, de acordo com modalidades de exemplo da presente descrição.

[0029] As Figuras 11 e 12 mostram fluxogramas que ilustram um procedimento exemplar para exibir dados médicos provenientes de vários dispositivos médicos em um único visor, de acordo com uma modalidade de exemplo da presente descrição.

[0030] As Figuras 13 e 14 mostram diagramas do monitor do paciente da Fig. 4, que fornece parâmetros de configuração para a exibição de dados provenientes do motor de integração de exemplo das Figuras 1 e 5 a 9, de acordo com modalidades de exemplo da presente descrição.

[0031] A Fig. 15 mostra um diagrama de conversão de dados fornecida por um ou mais motores de integração no exemplar ambiente de um hospital da Fig. 1, de acordo com modalidades de exemplo da presente descrição.

Descrição Detalhada

[0032] A presente descrição refere-se, em geral, a um método, um sistema, e um aparelho para integrar e simultaneamente exibir dados provenientes de diferentes tipos de dispositivos médicos com um único visor ou interface de usuário. O método, sistema, e aparelho de exemplo são configurados para superar limitações conhecidas de sistemas hospitalares ao fornecer um módulo, referido neste documento como um motor de integração, que é configurado para melhorar a interoperatividade de dispositivos médicos ao converter dados provenientes de múltiplos formatos, protocolos, ou padrões para um formato único. Apesar dos esforços da iniciativa da Integrating the Healthcare Enterprise (“IHE”) e da fundação Association for the Advancement of Medical Instrumentation (“AAMI”), não existem padrões nacionais ou internacionais para dispositivos médicos. Por exemplo, muitos fabricantes de bombas de infusão têm padrões ou protocolos diferentes para fornecer verificação de infusão point-of-care (“PIV”), dispositivo de comunicação de empresa (“DEC”), vinculação de identificação de paciente (“PIB”), e gerenciamento de comunicação de alarme (“ACM”). O resultado é que os dados de infusão provenientes de diferentes tipos de bombas de infusão podem ter diferentes modos nos quais os dados, parâmetros ou campos são rotulados. As diferenças podem ainda incluir os tipos ou unidades para a rotulagem dos dados, como é registrado o tempo dos dados, ou mesmo com que frequência os dados são transmitidos. Instalações médicas, neste sentido, normalmente têm de utilizar dispositivos médicos de um único fornecedor (ou de um grupo de fornecedores que utilizam o mesmo padrão). Estes sistemas conhecidos são, por essa razão, limitados em suas habilidades de utilizar dados provenientes de vários dispositivos médicos para construir uma avaliação de saúde completa de um paciente com o objetivo de fornecer uma programação de dispositivo dinâmica, ajuste de limite de programação, ajuste de limite de alarme, ou mesmo a simultânea exibição dos dados com um único visor ou interface de usuário.

[0033] O motor de integração exemplar divulgado neste documento é configurado como um módulo tendo várias interfaces, cada uma das quais, por sua vez, configurada para converter dados de um padrão ou protocolo para um padrão comum. A conversão de todos os dados médicos relevantes no motor de integração permite que o motor de integração seja programado para analisar os diferentes tipos de dados para identificar tendências, determinar diferenças ou correlações, ajustar limites/alarmes, e/ou ajustar parâmetros de programação, por exemplo. Em adição, o motor de integração pode ser utilizado em conjunção com um dispositivo de visor ou monitor para visualmente fornecer os diferentes tipos de dados médicos (e derivados dos mesmos) com uma interface única. A modularidade do motor de integração permite que atualizações de interface sejam fornecidas rápida e facilmente à medida que diferentes dispositivos médicos sejam introduzidos em um sistema ou à medida que os padrões de dados ou protocolos se alterem. Por conseguinte, o motor de integração exemplar melhora a interoperatividade do sistema como um todo.

[0034] Em um exemplo, o motor de integração é configurado para combinar os dados da bomba de infusão com os dados da terapia de insuficiência renal para permitir que o monitor do paciente simultaneamente exiba os dados da bomba de infusão e os dados da terapia de falha renal. O motor de integração do exemplo também pode realizar um ou mais cálculos com a utilização dos dados de infusão e da terapia de insuficiência renal com o objetivo de determinar um equilíbrio de fluidos. O motor de integração pode ainda integrar ou incorporar os dados em um ou mais algoritmos ou rotinas para simultaneamente exibir os dados em conjunção com o equilíbrio de fluidos calculado ou dados derivados para fornecer uma representação médica mais completa do paciente. O motor de integração ainda pode utilizar os dados da bomba de infusão e os dados derivados do equilíbrio de fluidos para ajustar os parâmetros da terapia de falha renal. Além disso, o motor de integração pode utilizar os dados da bomba de infusão, os dados da terapia de insuficiência renal, e/ou os dados derivados do equilíbrio de fluidos para fornecer umalarme quando, por exemplo, um equilíbrio de fluidos exceder um limiar específico e/ou quando uma drenagem da terapia de insuficiência renal não estiver agendada para um certo período de tempo.

[0035] Como mencionado acima, o motor de integração do exemplo facilita a exibição dos diferentes tipos de dados médicos, incluindo derivativos, com uma interface única. Como discutido neste documento, os dados médicos incluem dados provenientes de um dispositivo médico, o que inclui, por exemplo, dados de progresso de terapia, parâmetros/instruções de programação, parâmetros operacionais, mensagens de status, alarmes, alertas, etc. Os dados médicos podem ainda incluir dados fisiológicos ou medidos de outra maneira. Em um exemplo, os dados médicos provenientes de uma bomba de infusão incluem uma taxa de infusão, uma dosagem de infusão, um tempo de progresso da infusão, um status operacional da bomba de infusão (por exemplo, pausada), um volume de fluido restante a ser injetado, uma indicação de se um limite de documentação do medicamento foi excedido ou revogado, alarmes de bomba, alertas de bomba, e/ou derivativos dos mesmos.

[0036] Como discutido neste documento, os dados derivados podem incluir uma combinação de dados médicos recebidos a partir de um ou mais dispositivos médicos que não é determinante de nenhum fluxo de dados isolado. A combinação pode compreender, por exemplo, adição, subtração, ou execução de um programa especializado ou rotina que incorpore os dados médicos provenientes de um ou mais dispositivos. Os dados derivados também podem incluir uma análise que compare pelo menos alguns dados médicos provenientes de um ou mais dispositivos médicos a distribuições de dados. Os dados derivados podem ainda incluir um resultado da execução de uma análise estatística dos dados médicos. Em alguns casos, o motor de integração pode incluir um ou mais algoritmos ou rotinas pré-armazenados ou pré- configurados para determinar os dados derivados. Os dados derivados pré-configurados podem corresponder aos tipos de dados derivados usados com mais frequência. Em outros exemplos, o motor de integração exemplar pode permitir que um médico especifique como os dados derivados devem ser determinados ou gerados a partir dos dados médicos recebidos. Seria apreciado que o recurso de conversão divulgado do motor de integração exemplar facilite a criação dos dados derivados a partir de diferentes tipos de dados médicos que podem ser gerados em um ou mais protocolos ou padrões diferentes. Este recurso de conversão permite que dados provenientes de muitos dispositivos diferentes e padrões sejam normalizados ou formatados em um padrão ou protocolo (frequentemente compatível com o dispositivo que exibe os dados), que permite que vários fluxos de dados diferentes sejam comparados, combinados, integrados, ou analizados em conjunto. Sob uma tal configuração, o motor de integração permite que os mesmos cálculos sejam executados e os dados sejam exibidos independentemente do modelo ou fabricante dos sensores e/ou dispositivos médicos.

[0037] A Fig. 1 mostra um diagrama de um ambiente de um hospital 100 configurado para implementar os exemplos de métodos, aparelhos e sistema descrito neste documento, de acordo com uma modalidade de exemplo da presente descrição. O ambiente 100 de exemplo inclui dispositivos médicos tais como, por exemplo, uma bomba de infusão 102, uma máquina de terapia de insuficiência renal (“RFT”) ou diálise 104, um monitor do paciente 106, e/ou um ou mais sensores fisiológicos 108 (por exemplo, sensores de sinais vitais). Seria apreciado que o ambiente de hospital 100 exemplar pode incluir outros tipos de dispositivos médicos e/ou uma pluralidade de bombas 102, máquinas RFT 104, monitores 106, e/ou sensores 108. Coletivamente, os dispositivos médicos são configurados para fornecer uma terapia para um paciente 110, ler um parâmetro fisiológico ou sinal vital do paciente, e/ou exibir dados referentes ao paciente ou tratamento.

[0038] O ambiente 100 exemplar também inclui uma porta de infusão 112, uma porta RFT 114, e uma porta de monitor 116. Em modalidades alternativas, as portas 112, 114, e 116 podem ser combinadas em uma porta única. Em outras modalidades alternativas, as portas 112, 114, e 116 podem ser combinadas com os respectivos dispositivos médicos 102, 104 e 106. Como ilustrado na Fig. 1, a porta de infusão 112 e a porta RFT 114 são acopladas de forma comunicativa à porta do monitor 116 por meio de uma conexão por fios e/ou por uma conexão sem fio (por exemplo, uma rede Ethernet, LAN, WLAN, etc.). As portas 112, 114, e 116 são, cada uma, acoplada de forma comunicativa a uma rede 118, que pode incluir a mesma rede Ethernet, LAN, WLAN, e/ou em adição a uma rede externa tal qual a Internet. A rede 118 é acoplada de forma comunicativa a um sistema de informação hospitalar (“HIS”) 120, a uma ou mais redes médicas 122, e/ou a um ou mais dispositivos clínicos 124.

[0039] A bomba de infusão 102 do exemplo pode incluir qualquer bomba capaz de entregar uma terapia intravenosa para o paciente 110 por meio de um ou mais conjuntos de linhas. Exemplos incluem uma bomba de seringa, uma bomba peristáltica linear, uma bomba de grande volume (“LVP”), uma bomba de ambulatório, uma bomba multi-canais, etc. Uma bomba de seringa utiliza um motor conectado a um braço de acionamento para atuar um êmbolo com a seringa. Uma bomba peristáltica linear utiliza um rotor para comprimir parte de um tubo enquanto realiza a rotação. Frequentemente, um ou mais rolos do rotor faz contato com o tubo por metade de uma rotação. A rotação comprimida faz com que uma quantidade definida de fluido passe através do tubo. LVPs normalmente utilizam umou mais dedos ou braços para comprimir uma porção do tubo de terapia intravenosa (“IV”). A temporização da atuação do dedo sobre o tubo faz com que um movimento constante ou quase constante do fluido atravessa o tubo.

[0040] A Fig. 2 mostra um diagrama de uma bomba de infusão 102 exemplar que inclui a bomba Baxter® SIGMA SpectrumTM, de acordo com uma modalidade exemplar da presente descrição. A bomba de infusão 102 exemplar da Fig. 2 inclui um visor 202 com interfaces 204a e 204b para permitir que um médico especifique ou programe uma terapia de infusão. Outros exemplos de bombas de infusão incluem uma bomba parental de volume linear descrita na publicação dos Estados Unidos N° 2013/0336814, uma bomba de seringa na publicação dos Estados Unidos N° 2015/0157791, uma bomba de infusão de ambulatório descrita na patente dos Estados Unidos N° 7.059.840, uma bomba de infusão descrita na patente dos Estados Unidos N° 5.395.320, e uma bomba de infusão descrita na patente dos Estados Unidos N° 5.764.034, a íntegra das quais é incorporada neste documento por referência. A bomba de infusão 102 pode também incluir a bomba de infusão volumétrica Baxter® ColleagueTM.

[0041] Retornando à Fig. 1, a bomba de infusão 102 pode ser configurada para receber prescrições eletrônicas (ou atualizações de software) a partir do HIS 120 ou de outro sistema de farmácia por meio da porta de infusão 112. Por exemplo, a porta 112 pode enviar uma prescrição eletrônica (ou atualização de software) para a bomba de infusão 102 em um tempo prdeterminado e/ou quando a bomba de infusão 102 estiver disponível para aceitar a prescrição. Em outros casos, a bomba de infusão 102 pode ser configurada para periodicamente pesquisar a porta 112 para determinar se uma prescrição eletrônica (ou atualização de software) está aguardando para ser descarregada para a bomba. A bomba de infusão 102 pode incluir uma memória que armazena uma ou mais bibliotecas de medicamentos que inclui um limite de parâmetro de programa particular com base na área que deve ser tratada, mudança de dose, taxa de mudança, tipo de medicamento, concentração, idade do paciente, peso do paciente, etc. Os limites são configurados para garantir que uma prescrição recebida ou uma terapia de infusão introduzida esteja dentro de limites e/ou faixas aceitáveis decididos por uma instalação médica, médico ou clínico.

[0042] A bomba de infusão 102 é configurada para realizar uma terapia de infusão em um paciente 110, que inclui a infusão de uma ou mais soluções 103 ou medicamentos no paciente. A bomba de infusão 102 funciona de acordo com uma prescrição de infusão introduzida por um clínico em uma interface de usuário da bomba (por exemplo, a interface 204 da Fig. 2) ou recebida por meio da porta de infusão 112. A bomba de infusão 102 pode comparar a prescrição com a biblioteca de medicamentos e fornecer alguns alertas ou alarmes caso um parâmetro da prescrição viole um limite rígido ou leve. A bomba de infusão 102 é configurada para monitorar o progresso da terapia e periodicamente transmitir os dados de progresso da terapia de infusão 130 para a porta 112. Os dados de progresso da terapia 130, como divulgado neste documento, podem incluir, por exemplo, uma taxa de infusão, dose, um volume total injetado, um tempo restante para a terapia, a concentração do medicamento, mudança de taxa, um volume restante dentro do recipiente do medicamento, um nome do medicamento, um identificador do paciente, informação de titulação, informação de bolo, umidentificador de área tratada, um registro de tempo de quando os dados foram gerados, uma condição de alarme, uma condição de alerta, um evento, etc. A bomba de infusão 102 pode transmitir os dados de maneira contínua, periodicamente (por exemplo, a cada 30 segundos, 1 minuto, etc.), ou de acordo com a solicitação da porta 112.

[0043] A porta de infusão 112 da Fig. 1 inclui um servidor, um processador, um computador, etc., configurados para se comunicar com a bomba de infusão 102. A porta de infusão 112 pode incluir, por exemplo, a porta Baxter® CareEverywhere. Em algumas modalidades, a porta 112 pode ser acoplada de forma comunicativa a mais do que uma bomba de infusão. A porta de infusão 112 é configurada para fornecer uma comunicação bidirecional com a bomba 102 para uma transferência segura cabeada/sem fio para as bibliotecas de medicamentos, prescrições de infusão, e dados de progresso da terapia 130. A porta 112 pode também ser configurada para se integrar com o HIS 120 ou outro sistema hospitalar com o objetivo de facilitar a transmissão dos dados de progresso da terapia de infusão 130 provenientes da bomba 102 para, por exemplo, um registro médico eletrônico do hospital (“EMR”).

[0044] O HIS 120 da Fig. 1 é um sistema em rede configurado em uma arquitetura cliente-servidor para facilitar a transmissão dos dados médicos, incluindo os dados 130, 140 e 150, entre diferentes sistemas médicos. O HIS 120 pode incluir um ou mais servidores configurados para processar ou armazenar os dados médicos. O HIS 120 pode também incluir um ou mais servidores para analisar os dados médicos ou para receber os dados médicos provenientes de outras partes do ambiente de hospital 100. O HIS 120 pode incluir, por exemplo, um servidor para gerenciar o armazenamento de dados médicos para EMRs. O HIS 120 pode utilizar um identificador do paciente, ou algo semelhante, para determinar qual EMR deve receber os dados médicos a serem armazenados. O HIS 120 pode também incluir ou ser acoplado de forma comunicativa a um sistema de informação de laboratório, sistema de farmácia, um sistema de gerenciamento de procedimento/política, ou um sistema de melhoria de qualidade contínua (“CQI”). O sistema de laboratório é configurado para gerar dados médicos com base na análise das amostras biológicas do paciente. O sistema de farmácia é configurado para gerar prescrições médicas para um paciente, o que inclui instruções para a programação da bomba de infusão 102 e/ou da máquina RFT 104. O sistema de gerenciamento de procedimento/política é configurado para gerenciar as bibliotecas de medicamentos e/ou os limites para alertas/alarmes. O sistema CQI é configurado para gerar relatórios analíticos e/ou estatísticos com base em, por exemplo, os dados de progresso da terapia de infusão 130 de um ou mais pacientes. O HIS 120 pode também incluir ou ser conectado a um ou mais monitores para exibir pelo menos uma parte dos dados de progresso da terapia de infusão 130. O HIS 120 pode ainda integrar os dados de progresso da terapia de infusão 130, os dados de progresso da terapia de insuficiência renal 140, e/ou os dados fisiológicos 150 em uma documentação clínica com o objetivo de fornecer um rápido e preciso acesso e documentação da bomba de infusão para tendências próximas ao tempo real, e dados de infusão do paciente contextuais que melhorem o tratamento do paciente.

[0045] A máquina RFT 104 do exemplo da Fig. 1 pode incluir qualquer máquina de hemodiálise, hemofiltração, hemodiafiltração, terapia de substituição renal contínua (“CRRT”), ou diálise peritoneal (“PD”). O paciente 110, que passa por uma terapia de insuficiência renal, por exemplo, é ligado à máquina RFT 104, onde o sangue do paciente pode ser bombeado através da máquina. O sangue passa através de um dialisador da máquina 104, que remove resíduos, toxinas e excesso de água do sangue. O sangue limpo é devolvido ao paciente. Na PD, o fluido de tratamento é entregue para e removido de uma cavidade peritoneal do paciente com o objetivo de remover as toxinas e o excesso de água.

[0046] A Fig. 3 mostra um diagrama de um exemplo de máquina RFT 104 compreendendo a máquina Gambro® Prismaflex® CRRT, de acordo com uma modalidade exemplar da presente descrição. Outros exemplos de máquinas RFT 104 incluem uma máquina de diálise peritoneal descrita na patente dos Estados Unidos N° 8.403.880, uma máquina de diálise de hemodiálise descrita na publicação dos Estados Unidos N° 2014/0112828, e uma máquina de diálise peritoneal descrita na publicação dos Estados Unidos N° 2011/0106002, a íntegra das quais são incorporadas neste documento por referência.

[0047] A CRRT é uma modalidade de diálise normalmente utilizada para o tratamento de doenças críticas ou de emergência, pacientes hospitalizados em uma unidade de tratamento intensivo que desenvolvem insuficiência renal aguda (“AKI”). Diferente de doenças renais crônicas, que ocorrem lentamente com o passar do tempo, AKI frequentemente ocorre em pacientes hospitalizados e normalmente ocorre em um prazo de poucas horas a poucos dias.

[0048] A hemodiálise é um tratamento de insuficiência renal, na qual resíduos provenientes do sangue são difundidos através de uma membrana semipermeável. Durante a hemodiálise, o sangue é retirado do paciente e flui através de um conjunto de membrana semipermeável (dialisador), onde o sangue flui geralmente na contracorrente de uma solução de diálise que flui no outro lado da membrana semipermeável. No dialisador, as toxinas provenientes do sangue se deslocam através da membrana semipermeável e saem do dialisador em uma solução de diálise usada (solução de diálise). O sangue limpo, tendo fluido através do dialisador, é, em seguida, devolvido para o paciente.

[0049] No dialisador, um diferencial de pressão é criado através da membrana semipermeável ao remover a solução de diálise em uma taxa de fluxo que é maior do que aquela utilizada para introduzir a solução de diálise no dialisador. Esse diferencial de pressão puxa o fluido contendo pequenas, médias e grandes moléculas de toxinas através da membrana semipermeável. Medições de fluxo e volume são utilizadas para controlar a quantidade de fluido (ultrafiltragem) que é removido. Como ilustrado acima, uma bomba da máquina de hemodiálise normalmente puxa o sangue proveniente do lado da artéria do paciente, empurrando-o para dentro e através do dialisador, e através de uma câmara de gotejamento que elimina o ar, antes de devolver o sangue dialisado para o lado venoso do paciente.

[0050] A máquina RFT 104 pode, como alternativa, ser uma máquina de hemofiltração. A hemofiltração é um outro tratamento de insuficiência renal, semelhante à hemodiálise. Durante a hemofiltração, o sangue do paciente também é passado através de uma membrana semipermeável (um hemofiltro), no qual um fluido (que inclui produtos residuais) é puxado através da membrana semipermeável por um diferencial de pressão. Este fluxo convectivo traz certos tamanhos de toxinas moleculares e eletrólitos (que são difíceis para a hemodiálise limpar) através da membrana semipermeável. Durante a hemofiltração, um fluido de substituição é adicionado ao sangue para substituir o volume do fluido e eletrólitos removidos do sangue por meio do hemofiltro. A hemofiltração na qual um fluido de substituição é adicionado ao sangue antes do hemofiltro é conhecida como hemofiltração pré-diluição. A hemofiltração na qual um fluido de substituição é adicionado ao sangue depois do hemofiltro é conhecida como hemofiltração pós-diluição.

[0051] A máquina RFT 104 pode, como alternativa, ser uma máquina de hemodiafiltração. A hemodiafiltração é um outro tratamento de insuficiência renal que utiliza a hemodiálise em combinação com a hemofiltração. O sangue é bombeado através de um dialisador, que aceita um fluido de diálise fresco, diferente de um hemofiltro. Com a hemodiafiltração, no entanto, o fluido de substituição é entregue na corrente sanguínea, de modo semelhante à hemofiltração. A hemodiafiltração é, neste sentido, um vizinho da hemodiálise e da hemofiltração.

[0052] A máquina RFT 104 pode, como alternativa, ser uma máquina de diálise peritoneal. A diálise peritoneal utiliza uma solução de diálise, também chamada solução de diálise, que é injetada na cavidade peritoneal do paciente por meio de um cateter. A solução de diálise entra em contato com a membrana peritoneal da cavidade peritoneal do paciente. Os resíduos, as toxinas e o excesso de água passam do fluxo sanguíneo do paciente, através da membrana peritoneal e para a solução de diálise devido a um gradiente osmótico criado pela solução. A solução de diálise gasta 105 é drenada do paciente, removendo resíduos, toxinas e excesso de água do paciente. Esse ciclo é repetido.

[0053] Um exemplo de máquina de diálise peritoneal, que opera como uma máquina RFT 104 da Fig. 1, pode realizar vários tipos de terapias de diálise peritoneal adicionais, incluindo a diálise peritoneal cíclica contínua (“CCPD”), a diálise peritoneal automatizada de fluxo caudal (“APD”), e a diálise peritoneal de fluxo contínuo (“CFPD”). As máquinas APD executam a drenagem, preenchimento e permanência de ciclos automaticamente, normalmente enquanto o paciente dorme. As máquinas APD liberam os pacientes ou os clínicos de terem de executar os ciclos de tratamento de forma manual e de terem de transportar suprimentos durante o dia. As máquinas APD se conectam de maneira fluida com um cateter implantado, uma fonte ou bolsa de solução de diálise fresca, e uma drenagem de fluido. As máquinas APD bombeiam a solução de diálise fresca a partir de uma fonte de solução de diálise, através do cateter, para o interior da cavidade peritoneal do paciente. As máquinas APD permitem que a solução de diálise permaneça dentro da cavidade, deste modo permitindo que a transferência de resíduos, toxinas e excesso de água ocorra. A fonte pode ser várias bolsas de solução de diálise estéreis. As máquinas APD bombeiam a solução de diálise gasta a partir da cavidade peritoneal, através do cateter, para a drenagem. Assim como com o processo manual, muitos ciclos de permanência, preenchimento e drenagem ocorrem durante a APD. Um “último preenchimento” ocorre no final da CAPD e APD, que permanecerá na cavidade peritoneal do paciente até o próximo tratamento.

[0054] Os tratamentos CCPD tentam drenar o paciente completamente a cada drenagem. O CCPD e/ou o APD podem ser sistemas do tipo lote que enviam o fluido de solução de diálise gasta para um dreno. Os sistemas de fluxo caudal são sistemas de lote modificados. Com o fluxo caudal, ao invés de remover todo o fluido do paciente durante um longo período de tempo, uma porção do fluido é removida e substituída após pequenos incrementos de tempo.

[0055] As soluções de diálise da diálise peritoneal podem incluir uma solução ou mistura que inclui entre 0,5% e 10% de dextrose (ou mais geralmente glicose), de preferência entre 1,5% e 4,25%. As soluções de diálise da diálise peritoneal podem incluir, por exemplo, as soluções de diálise Dianeal®, Physioneal®, Nutrineal®, e Extraneal® comercializados pelo titular da presente descrição. A solução de diálise pode adicionalmente ou como alternativa incluir uma porcentagem de icodextrina. Seria apreciado que em algumas modalidades da presente descrição, a solução de diálise possa ser injetada no paciente 110 por meio da bomba de infusão 102 em vez de pela máquina RFT 104.

[0056] Os sistemas de diálise de fluxo contínuo, ou CFPD, limpam ou regeneram a solução de diálise gasta ao invés de descarta-la. Os sistemas CFPD bombeiam o fluido para dentro e para fora do paciente, através de um ciclo. A solução de diálise flui para dentro da cavidade peritoneal através de um cateter lúmen e para fora através de outro cateter lúmen. O fluido que sai do paciente passa através de um dispositivo de reconstituição que remove os resíduos da solução de diálise, por exemplo, por meio de uma coluna de remoção de ureia que emprega urease para enzimaticamente converter em ureia em amônia (por exemplo, cátion de amônia). A amônia é, em seguida, removida da solução de diálise por adsorção antes da reintrodução da solução de diálise na cavidade peritoneal. Sensores adicionais são empregados para monitorar a remoção da amônia. Os sistemas CFPD são normalmente mais complicados do que os sistemas de lote.

[0057] Em ambas, a hemodiálise e a diálise peritoneal, uma tecnologia “adsorvente” pode ser utilizada para remover toxinas urêmicas da solução de diálise residual, reinjetar agentes terapêuticos (tais como íons e/ou glicose) no fluido tratado, e reutilizar esse fluido para continuar a diálise do paciente. Um adsorvente comumente utilizado é feito a partir de fosfato de zircônio, que é utilizado para remover a amônia gerada a partir da hidrólise da ureia. Normalmente, uma grande quantidade de adsorvente é necessária para remover a amônia gerada durante os tratamentos de diálise.

[0058] De modo semelhante às bombas de infusão 102, a máquina RFT 104 pode ser programada localmente com uma prescrição de diálise ou receber uma prescrição de diálise por meio da porta RFT 114. A máquina RFT 104 é configurada para executar a terapia de insuficiência renal no paciente 110, que, conforme discutido acima, inclui a remoção da ultrafiltração do paciente 110. Com a diálise peritoneal, a máquina RFT 104 injeta uma solução de diálise no paciente 110 durante os ciclos de preenchimento. Para qualquer prescrição de diálise, a máquina RFT 104 pode comparar os parâmetros da prescrição com um ou mais limites e fornecer quaisquer alertas ou alarmes caso um parâmetro da prescrição viole um limite rígido ou leve. A máquina RFT 104 é configurada para monitorar o progresso da terapia e periodicamente transmitir os dados de progresso da terapia de insuficiência renal 140 para a porta RFT 114. Os dados de progresso da terapia de insuficiência renal 140 podem incluir, por exemplo, uma taxa de preenchimento, um tempo de permanência, uma taxa de remoção de fluido ou drenagem, uma taxa de fluxo sanguíneo, uma dose de efluente, uma taxa de remoção de ultrafiltração, uma taxa de remoção de solução de diálise, um total de solução de diálise injetada, um fluxo de solução de diálise, um pré-fluxo de substituição, um pós-fluxo de substituição, um equilíbrio de peso do paciente, uma pressão de retorno, um sinal de excesso de fluidos do paciente, uma fração de filtração, um tempo restante, uma concentração da solução de diálise, um nome da solução de diálise, um identificador do paciente, um identificador do quarto, um identificador da área de tratamento, um registro do tempo em que os dados foram gerados, uma condição de alarme, uma condição de alerta, um evento, etc. A máquina RFT 104 pode transmitir os dados de forma contínua, periódica (por exemplo, a cada 30 segundos, 1 minuto, etc.), ou respondendo à solicitação da porta RFT 114.

[0059] A porta RFT 114 inclui um servidor, um processador, um computador, etc., configurada para se comunicar com a máquina RFT 104. A porta RFT 114 pode incluir, por exemplo, a porta ou servidor Global Baxter ExchangeTM (“GBX”). A porta 114 pode ser acoplada de forma comunicativa com mais de uma máquina RFT. A porta RFT 114 é configurada para fornecer uma comunicação bidirecional com a máquina 104 para a transferência segura cabeada/sem fios das bibliotecas de medicamentos, prescrições de diálise, e dados de progresso da terapia de insuficiência renal 140. A porta 114 pode ser também configurada para se integrar com ou se comunicar com o HIS 120 ou outro sistema hospitalar com o objetivo de transmitir os dados de progresso da terapia de insuficiência renal 140 a partir da máquina RFT 104 para um EMR do paciente. Os dados de progresso da terapia de insuficiência renal 140 também podem ser utilizados pelo HIS 120 para análise, relatórios e/ou consultas.

[0060] O exemplo de monitor de paciente 106 da modalidade ilustrada na Fig. 1 é configurado para exibir um ou mais gráficos de dados fisiológicos 107 provenientes do sensor fisiológico 108. O monitor 106 pode ser acoplado por cabos ou sem fios ao sensor 108, que pode incluir, por exemplo, um sensor de taxa cardíaca (por exemplo, um sensor EKG, um sensor ECG), um sensor de temperatura, um sensor de oximetria de pulso, uma escala de peso do paciente, um sensor de glicose, um sensor respiratório, um sensor de pressão sanguínea, etc. O monitor do paciente 106 é configurado para exibir os dados provenientes dos sensores com um gráfico baseado em tempo. O monitor do paciente 106 pode também exibir um valor numérico dos dados mais recentes provenientes do sensor 108 em adição a uma codificação por cor dos dados. De forma coletiva, os dados recebidos no monitor do paciente 106 a partir dos sensores 108 podem ser referidos, neste documento, como os dados fisiológicos 150.

[0061] O monitor do paciente 106 é acoplado de modo comunicativo com a porta de monitor 116. O monitor do paciente 106 pode de maneira contínua, periodicamente, ou sob demanda, transmitir os dados fisiológicos 150 para a porta de monitor 116, que pode, em seguida, transmitir os dados fisiológicos 150 para o HIS 120 para a inclusão no EMR do paciente ou com os registros do clínico. Os dados fisiológicos 150 também podem ser utilizados com os dados 130 e 140 dentro de um sistema CQI ou transmitidos para o dispositivo clínico 124.

[0062] O exemplo de porta de monitor 116 da Fig. 1 inclui um motor de integração 160 configurado para processar os dados 130, 140 e 150 respectivamente provenientes da bomba de infusão 102, da máquina RFT 104, e do monitor do paciente 106. O motor de integração 160 de exemplo é configurado para analisar os dados 130, 140 e 150 em conjunção com uma ou mais rotinas, algoritmos, etc., com o objetivo de determinar como os dados devem ser exibidos e/ou apresentados. Por exemplo, enquanto o monitor do paciente 106 é configurado para exibir os dados fisiológicos 150 a partir de sensores 108 conectados, o monitor do paciente 106 pode não ser configurado para exibir os dados 130 e 140. Em algumas modalidades, os dados 130 e 140 podem estar em um padrão ou formato que não é compatível ou reconhecível pelo monitor do paciente 106.

[0063] O motor de integração 160 é configurado para converter ou, de outra maneira, formatar os dados 130 e 140 para um padrão, formato ou protocolo que seja compatível com o monitor 106 (por exemplo, referido neste documento como um formato comum). O motor de integração 160 também é configurado para determinar quais dentre os dados de infusão 130 e os dados de diálise 140 devem ser exibidos em um tempo particular e instruir o monitor 106 a exibir os dados formatados ou convertidos em conjunto com os dados fisiológicos 150 em um tempo específico. O resultado é a exibição simultânea dos dados de infusão e dos dados da terapia de insuficiência renal com os dados fisiológicos a partir do mesmo tempo. Uma tal configuração permite que um médico visualize, em um único local, os dados de infusão, os dados da terapia de insuficiência renal, e os dados fisiológicos, e seja capaz de determinar rapidamente como uma alteração na terapia de insuficiência renal ou infusão pode afetar a condição fisiológica do paciente.

[0064] O simultâneo processamento, integração, e conversão dos dados 130, 140 e/ou 150 permite que o motor de integração 160 também determine condições, deltas, ou derivativos com base nos diferentes tipos de dados. Por exemplo, o motor de integração 160 pode incluir uma rotina que compare uma quantidade de fluido injetada em um paciente com o fluido removido do paciente através da diálise ou terapia de insuficiência renal com o objetivo de determinar os dados derivados indicativos do equilíbrio de fluidos. O motor de integração 160 pode, em seguida, calcular uma nova diferença de fluidos e fornecer esta informação ao monitor 106 para a simultânea visualização com os dados da terapia de insuficiência renal 140 e infusão.

[0065] Uma tal configuração também permite que o motor de integração 160 forneça alarmes e/ou alertas melhorados. Por exemplo, o motor de integração 160 pode ser configurado para executar uma rotina que compare os parâmetros fisiológicos do paciente com limites rígidos, limites leves, ou limites delta. O motor de integração 160 pode também analisar os dados de progresso de terapia 130 e/ou os dados de terapia de insuficiência renal 140 em conjunto com um ou mais limites. Em um exemplo, o motor de integração 160 pode detectar que os parâmetros fisiológicos de um paciente estão tendendo para um nível perigoso e ativar um alarme para alterar (ou interromper) a terapia de infusão ou a terapia de falha renal. Em um outro exemplo, o motor de integração 160 pode detectar que uma condição fisiológica está se aproximando de um primeiro limite. No entanto, o motor de integração 160 também determina que uma infusão está ocorrendo e que um segundo limite mais elevado deve ser usado ao invés do primeiro.

[0066] Deve ser apreciado que ao ter acesso a diferentes tipos de dados 130, 140 e 150, permite que o motor de integração 160 forneça melhorias incontáveis para a interoperabilidade e para o tratamento do paciente. O motor de integração 160 pode ser configurado para, de forma dinâmica, ajustar os limites operacionais do dispositivo médico e/ou os limiares de alerta/alarme com base em certos dados 130, 140 e 150 (e/ou derivativos dos mesmos). Por exemplo, a bomba de infusão 102 normalmente inclui uma ou mais bibliotecas de medicamentos que definem limites de parâmetros operacionais com base no peso do paciente, gênero, área de tratamento, etc. A utilização do motor de integração 160 permite que pelo menos um dos limites seja especificado por rotinas e/ou algoritmos com base em certos dados. Por exemplo, um limite de dosagem de infusão pode ser ajustado com base em um tipo de terapia de insuficiência renal que está sendo fornecida simultaneamente. Em outros exemplos, o motor de integração 160 pode ajustar as configurações de prescrição com base na análise dos dados 130, 140 e/ou 150 (e derivativos dos mesmos). Por exemplo, uma taxa de infusão pode ser diminuída (de acordo com uma rotina específica) se os dados de progresso da terapia de insuficiência renal 140 indicarem que o paciente 110 está acumulando fluidos em demasia. Para alterar um limite ou parâmetro operacional, o motor de integração 160 pode ser configurado para criar instruções em um padrão de mensagens apropriado para que a bomba de infusão 102 faça com que os limites ou parâmetros operacionais sejam ajustados.

[0067] O motor de integração 160 de exemplo pode também facilitar a utilização de alarmes e/ou alertas com limiares e/ou condições de disparo dinâmicas. Por exemplo, o motor de integração pode analisar os dados 130, 140 e/ou 150 (e derivativos dos mesmos) para determinar se certos limites para alarmes/alertas da bomba de infusão 102 e/ou da máquina RFT 104 devem ser ajustados. Responsivo à detecção de que um limite deve ser alterado, o motor de integração 160 transmite uma ou mais mensagens para o apropriado dispositivo 102 ou 104 que indica a alteração do limite. O motor de integração 160 é configurado para utilizar um ou mais algoritmos e/ou rotinas para determinar como a combinação dos dados 130, 140 e/ou 150 (e derivativos dos mesmos) afeta os limites de alerta/alarme.

[0068] O motor de integração 160 de exemplo pode também ser configurado para gerar os seus próprios alertas e/ou alarmes com base nos dados 130, 140 e/ou 150 (e derivativos dos mesmos). O motor de integração 160 pode incluir uma lista ou tabela de alarmes/alertas e condições de limites correspondentes. O motor de integração compara os dados 130, 140 e/ou 150 apropriados (e derivativos dos mesmos) com a lista para determinar se um alarme/alerta deve ser gerado. A tabela pode também especificar um destino para o qual o alarme/alerta deve ser transmitido. Por exemplo, os alarmes/alertas podem ser transmitidos para um visor ou atuador de áudio na bomba de infusão 102, na máquina RFT 104, e/ou no monitor do paciente 106. Adicionalmente ou como alternativa, o motor de integração 160 pode transmitir os alarmes/alertas para o HIS 120 ou outros sistemas médicos 122. Uma tal configuração permite, por exemplo, que alarmes ou alertas sejam gerados com base em combinações dos dados de progresso da terapia 130, dos dados de progresso da terapia de insuficiência renal 140, dos dados fisiológicos 150, e/ou derivativos dos mesmos. Por exemplo, o motor de integração 160 pode gerar um alarme quando um equilíbrio de fluidos (que é derivado dos dados RFT e de infusão) exceder um limite. Além disso, o motor de integração 160 pode ser configurado para ajustar condições e/ou limiares para os alarmes/limites.

[0069] Em alguns casos, o motor de integração 160 pode fornecer instruções de programação em combinação com (ou em resposta a) os alarmes e/ou alertas. Por exemplo, o motor de integração 160 pode determinar um problema com a bomba de infusão 102 (ou receber um alarme proveniente da bomba de infusão 102) e determinar, com a utilização de uma rotina para analisar os dados, que a máquina RFT 104 deve ser suspendida. O motor de integração 160, em concordância, transmite uma ou mais mensagens, em um padrão apropriado à máquina RFT 104, para a máquina RFT 104, fazendo com que a máquina RFT 104 suspenda a operação.

[0070] Em algumas modalidades, o motor de integração 160 pode ser incluído com um computador, processador, e/ou servidor que esteja acoplado de forma comunicativa com a porta de monitor 116. Como alternativa, o motor de integração 160 pode ser distribuído entre um computador, a porta de monitor 116, e o monitor do paciente 106. Tais configurações permitem que um clínico modifique ou selecione (a partir de um computador ou smartphone) quais dados devem ser exibidos e quais rotinas devem ser utilizadas para o processamento dos dados 130, 140 e 150. A seleção realizada pelo clínico pode atualizar como a porta do monitor 116 direciona e/ou processa os dados e/ou como o monitor do paciente 106 processa os dados. Uma tal configuração também permite que uma funcionalidade de interface de usuário seja incluída em conjunção com os dados. Isto pode incluir o fornecimento de uma habilidade para que um clínico selecione uma quantidade líquida de uma forma de onda de um fluido ou veja uma forma de onda individual dos dados 130, 140 e 150, que contribua para a quantidade determinada.

[0071] Em algumas modalidades, a bomba de infusão 102 e/ou a máquina RFT 104 podem também estar acopladas de forma comunicativa com um ou mais sensores fisiológicos 108. Por exemplo, a bomba de infusão 102 pode estar conectada a um sensor de oximetria de pulso. A bomba de infusão 102 pode ser configurada para integrar, ou de outra maneira, incluir os dados provenientes do sensor de oximetria de pulso nos dados de progresso da terapia de infusão 130 ou, como alternativa, transmitir os dados de oximetria de pulso separadamente para a porta de infusão 112. De modo semelhante, a máquina RFT 104 pode estar acoplada de forma comunicativa a um sensor de pressão sanguínea, a uma escala de peso do paciente, a um sensor de glicose, a um monitor cardíaco, etc. A máquina RFT 104 pode ser configurada para integrar, ou de outra maneira, incluir os dados provenientes dos sensores nos dados de progresso da terapia de insuficiência renal 140 ou, como alternativa, transmitir os dados dos sensores separadamente para a porta RFT 114.

Modalidade exemplar

[0072] Deve ser apreciado que o monitoramento do equilíbrio de fluidos de um paciente é importante para prevenir a desidratação ou hiper-hidratação. No entanto, sistemas de registro de equilíbrio de fluidos conhecidos são notórios por serem inadequados ou imprecisos devido a esses sistemas exigirem uma separada coleta e inserção de informações de terapia de insuficiência renal e de infusão. No entanto, um clínico pode não registrar oportunamente as informações de infusão ou de terapia de falah renal ou pode registrar uma, mas não a outra. Em alguns casos, o clínico pode gastar algum tempo registrando as informações de infusão e, em seguida, as informações da terapia de falha renal. No entanto, a diferença de tempo entre a coleta das informações da terapia de insuficiência renal e de infusão pode produzir erros de correlação.

[0073] No ambiente de hospital 100 de exemplo na Fig. 1, a bomba de infusão 102 está bombeando ou injetando um fluido no paciente 110, ao tempo que a máquina RFT 104 remove um fluido 105 do paciente 110. A máquina RFt 104 pode estar preenchendo o paciente 110 com um fluido. Em um exemplo, a bomba d einfusão 102 pode injetar um ou mais medicamentos ou solução salina, enquanto a máquina RFT 104 está configurada para executar a hemodiálise ou a diálise peritoneal. Uma tal configuração pode ser utilizada para certos medicamentos que precisam ser removidos rapidamente após terem sido injetados ou em situações onde os medicamentos são administrados a pacientes com falhas renais.

[0074] As “entradas e saídas” de fluidos são um aspecto chave na determinação e gerenciamento de um estado hemodinâmico e fluido de um paciente. Antes do início do tratamento, as portas 112,114 e 116 são configuradas para direcionar e processar os dados de forma tal que todos os dados relacionados com o paciente 110 sejam agregados de modo que pelo menos alguns dos dados agregados possam ser integrados e/ou processados e exibidos. Neste caso, o monitor do paciente 106 pode receber, ou de outra maneira, obter um identificador do paciente 110. Por exemplo, um leitor de códigos de barras anexado ao monitor 106 pode ser utilizado para ler uma pulseira de um paciente 110. O monitor 106 pode, em seguida, transmitir o identificador em adição a um endereço de IP ou endereço MAC do monitor 106 para a porta 116, onde o motor de integração 160 faz a correlação do endereço do monitor 106 com o identificador do paciente.

[0075] Igualmente antes do tratamento, a bomba de infusão 102 e a máquina RFT 104 podem obter, ou de outra maneira, receber um identificador do paciente. Por exemplo, um leitor de código de barras embutido na bomba de infusão ou acoplado de forma comunicativa à bomba de infusão pode ler a pulseira do paciente ou um recipiente de medicamento para obter a identificação do paciente. A bomba de infusão 102 e a máquina RFT 104 incluem o identificador do paciente com os dados 130 e 140.

[0076] No decorrer do tratamento, a bomba de infusão 102 gera os dados de progresso da terapia de infusão 130, que são transmitidos para a porta 112, ao passo que a máquina RFT 104 gera os dados de progresso da terapia de insuficiência renal 140, que são transmitidos para a porta 114. As portas 112 e 114 do exemplo transmitem os respectivos dados para a porta do monitor 116. O monitor do paciente 106 de exemplo também transmite os dados fisiológicos 150 (incluindo o identificador do paciente) para a porta do monitor 106. O motor de integração 160 na porta de monitor 106 analisa os dados 130 e 140 para o identificador do paciente. Todos os dados com o mesmo identificador do paciente são, em seguida, processados pelo motor de integração 160 para a exibição no monitor do paciente 106. Por exemplo, o motor de integração 160 pode buscar todos os dados associados com o mesmo paciente pela informação de registro de tempo. O motor de integração 160 pode, em seguida, enviar os dados com o mesmo registro de tempo para o monitor do paciente 106 para a exibição dentro dos respectivos gráficos.

[0077] O motor de integração 160 de exemplo pode também calcular ou processar os dados 130, 140, e 150, para especificar os parâmetros ou valores derivativos. Por exemplo, o motor de integração 160 pode utilizar uma taxa de infusão proveniente da bomba de infusão 102 e uma taxa de remoção de fluido de diálise proveniente da máquina RFT 104 para determinar a acumulação de fluidos líquida no paciente 110. O motor de integração 160 pode, em seguida, anexar umregistro de tempo aos dados de acumulação de fluidos líquido que corresponda ao registro de tempo da taxa de infusão e da taxa de remoção de fluidos de diálise. O motor de integração 160, em seguida, envia os dados de acumulação de fluidos líquido, a taxa de infusão, e a taxa de remoção de fluidos de diálise para o monitor 106 objetivando a exibição.

[0078] A Fig. 4 mostra um diagrama do monitor do paciente 106 exibindo os dados provenientes do motor de integração 160, de acordo com uma modalidade de exemplo da presente descrição. Uma interface de usuário 402 é configurada para exibir os dados de sensor fisiológicos 150 que incluem, por exemplo, dados EKG, dados respiratórios, dados de oximetria de pulso, e dados de pressão sanguínea. Em conjunção com os mais recentes valores, a interface de usuário 402 exibe uma linha de tempo ou gráfico de cada tipo de dado. Deve ser apreciado que a escala de linha de tempo para cada tipo de dado pode ser a mesma, mas poderiam ser diferentes com base nas seleções do usuário.

[0079] A interface de usuário 402 também mostra um valor numérico que ilustra uma quantidade de fluido por período de tempo (cc/hora) que tem sido ativamente injetada no paciente 110 por meio de uma bomba de infusão 102. O motor de integração 160 pode combinar os dados provenientes de todas as bombas de infusão 102 que estão conectadas ao paciente 110 e/ou os dados provenientes da máquina RFT 104. O motor de integração 160 pode, além disso, combinar as entradas de fluidos provenientes de outros dispositivos tais como, por exemplo, tubos de alimentação nutricional. Os dados são exibidos como uma forma de onda de taxa de entrada sobre um tempo recente em adição a um valor numérico que mostra um total de fluido injetado sobre um período de tempo recente configurável (por exemplo, as últimas 8 horas).

[0080] A interface de usuário 402, além disso, mostra um valor numérico que ilustra uma quantidade de fluido por período de tempo (cc/hora) que está sendo ativamente removida do paciente 110 por meio de uma máquina RFT 104. O motor de integração 160 pode combinar os dados provenientes de todas as máquinas RFT 104 conectadas ao paciente 110 e/ou dados provenientes de um dispositivo de coleta de urina (por exemplo, o sensor fisiológico 108). Os dados são exibidos como uma forma de onda de taxa de saída sobre um tempo recente em adição a um valor numérico que mostra um total de fluido removido sobre um período de tempo recente configurável (por exemplo, as últimas 8 horas).

[0081] A interface de usuário 402 de exemplo, além disso, mostra um valor numérico que ilustra uma quantidade líquida de mudança de fluido por período de tempo (por exemplo, cc/hora). Este dado derivativo é exibido como uma forma de onda de taxa líquida sobre um tempo recente em adição a um valor numérico que mostra uma mudança de fluido líquida sobre um período de tempo recente configurável (por exemplo, as últimas 8 horas).

[0082] O motor de integração 160 de exemplo pode também ser configurado para enviar instruções para o monitor 106 com relação a quais dados devem ser exibidos. Por exemplo, o motor de integração 160 pode apenas receber os dados 130 a partir da bomba de infusão 102. Em resposta, o motor de integração 160 pode enviar uma instrução para o monitor 106 indicando que somente uma linha de tempo ou uma forma de onda para a taxa de infusão deve ser exibido.

[0083] Como discutido acima, mais do que uma bomba de infusão 102 pode estar ligada ao paciente 110. Nestas circunstâncias, o motor de integração 160 pode agregar (de acordo com uma rotina pré- definida) a entrada de fluido para o paciente com base nos dados 130 provenientes de todas as bombas. Em adição, o motor de integração 160 pode ser configurado para criar uma lista ou uma estrutura de dados dos nomes das substâncias que estão sendo injetadas no paciente. O motor de integração 160 pode ordenar os nomes das várias substâncias e enviar a ordenação para o monitor 106 para a exibição com a interface de usuário 402. O motor de integração 160 pode ordenar os nomes com base na importância, criticidade para o paciente, taxa de infusão, etc. Em casos onde o número de nomes é maior do que a área do visor na interface de usuário 402, o motor de integração 160 de exemplo pode especificar quais nomes devem ser exibidos e quais nomes devem ser escondidos atrás de uma elipse. O motor de integração 160 pode definir a elipse como um campo de entrada, tal que, uma seleção feita pelo usuário faz com que o monitor 106 exiba os outros nomes, ou faz com que o motor de integração 160 envie os outros nomes.

[0084] O motor de integração 160 pode também determinar quais infusões estão ativas comparadas às infusões que estão pausadas ou finalizadas (com base em indicadores de estado ou informação de taxa de infusão especificada com os dados de progresso da terapia de infusão 130). O motor de integração 160 pode ordenar os nomes das infusões com base na atividade e/ou pode codificar por cor os nomes com base na atividade. Em alguns casos, o motor de integração 160 pode fazer com que o monitor 106 exiba, adjacente à quantidade líquida de forma de onda do fluido, uma indicação das infusões ativas.

[0085] Em alguns casos, cada um dos nomes também pode ser definido como um campo de entrada. A seleção de um nome particular pode fazer com que o motor de integração 160 exiba uma entrada fluida para o paciente para somente aquela substância selecionada. O motor de integração 160 pode também determinar para a exibição uma quantidade líquida de fluido entre os dados de diálise da substância de infusão selecionada. O motor de integração 160 pode ser configurado para executar esta quantidade líquida de entrada de fluido para várias seleções de substâncias de infusão que compreende um subconjunto do conjunto total das substâncias de infusão conhecidas.

[0086] Deve ser apreciado que o motor de integração 160 pode incluir um número ilimitado de rotinas que especificam como os dados 130, 140 e 150 (e derivativos dos mesmos) devem ser processados e configurados para a exibição. Algumas das rotinas podem ser pré- definidas com base em relacionamentos definidos entre os dados. Outras das rotinas podem ser especificadas por um operador no monitor 106. Por exemplo, um clínico pode selecionar quais tipos de dados devem ser exibidos no monitor 106. A seleção de certos tipos de dados pode fazer com que o motor de integração 160 execute uma rotina para determinar o tipo de dado selecionado.

[0087] O motor de integração 160 de exemplo também é configurado para garantir que os dados 130 e 140 estejam em um formato aceitável para a exibição pelo monitor do paciente 106. O motor 160 pode executar esta conversão ao receber os dados. Por exemplo, o motor de integração 160 pode incluir uma pluralidade de interfaces de programação de aplicações bem definidas (“APIs”) configuradas para aceitar dados provenientes dos respectivos dispositivos 102 e 104. As APIs podem definir como os campos ou a estrutura de pacotes devem ser convertidos e/ou analisados e direcionados para os pacotes ou campos correspondentes compatíveis com o monitor 106.

Modalidades Adicionais do Ambiente do Hospital

[0088] As Figuras de 5 a 9 mostram diagramas do ambiente de hospital 100 da Fig. 1 com o motor de integração 160 em operação em diferentes dispositivos, de acordo com modalidades exemplares da presente descrição. Por exemplo, a Fig. 5 mostra o motor de integração 160 incluído no monitor do paciente 106. Neste caso, o monitor do paciente 106 fornece os dados fisiológicos 150 para o motor de integração 160 sem a transmissão para outro dispositivo. O monitor do paciente 106 pode ainda enviar os dados fisiológicos 150 para a porta do monitor 116 para a inclusão com, por exemplo, um EMR. O uso do motor de integração 160 no monitor do paciente 106 pode fornecer respostas relativamente rápidas para uma entrada do usuário e/ou pode tornar a customização de rotinas ao lado da cama do paciente mais fáceis. Por exemplo, um clínico pode utilizar a interface de usuário 402 do monitor do paciente para selecionar quais dados devem ser exibidos ao invés de ter de conectar ou acessar a porta do monitor 116 para realizar a seleção.

[0089] As Figuras 6 e 7 ilustram que o motor de integração 160 pode estar incluído na porta RFT 114 e/ou na máquina RFT 104. Nestes casos, a leitura do identificador do paciente na máquina RFT 104 faz com que a máquina RFT 104 e/ou a porta RFT 114 transmita para a porta do monitor 116 e para a porta de infusão 112 que os dados que incluem o identificador do paciente devem ser direcionados para a porta RFT 114. Como alternativa, a leitura do identificador do paciente na máquina RFT 104 faz com que a máquina RFT 104 e/ou a porta RFT 114 subscrevam na porta de infusão 112 para os dados 130 relacionados com o identificador do paciente e subscrevam na porta de monitor 116 para os dados 150 relativos ao identificador do paciente. A subscrição para os dados faz com que a porta de infusão 112 e a porta do monitor 116 transmitam os dados 130 e 150 que incluem o identificador do paciente para a porta RFT 114 para a exibição na máquina RFT 104. Neste caso, o motor de integração 160 é configurado para converter os dados 130 e 150 para um formato que seja compatível com a máquina RFT 104. Uma tal configuração pode ser desejável quando, por exemplo, apenas uma máquina RFT e uma bomba de infusão estão ligadas ao paciente 110. Seria também apreciado que uma tal configuração eliminasse a necessidade do monitor do paciente 106 caso os sensores 108 possam estar acoplados de forma comunicativa com a máquina RFT 104 e/ou com a bomba de infusão 102.

[0090] As Figuras 8 e 9 ilustram que o motor de integração 160 pode estar incluído na porta de infusão 112 e/ou na bomba de infusão 102. Nestes casos, a leitura do identificador do paciente na bomba de infusão 102 faz com que a bomba de infusão 102 e/ou a porta de infusão 112 transmitam para a porta do monitor 116 e para a porta RFT 114 que os dados incluindo o identificador do paciente devem ser direcionados para a porta de infusão 112. Como alternativa, a leitura do identificador do paciente na bomba de infusão 102 faz com que a bomba de infusão 102 e/ou a porta de infusão 112 subscrevam na porta RFT 114 para os dados 140 relacionados com o identificador do paciente e subscrevam na porta do monitor 116 para os dados 150 relacionados com o identificador do paciente. A subscrição aos dados faz com que a porta RFT 114 e a porta do monitor 116 transmitam os dados 140 e 150, que incluem o identificador do paciente, para a porta de infusão 112 para a exibição na bomba de infusão 102. O motor de integração 160 é configurado para converter os dados 140 e 150 para um formato que seja compatível com a bomba de infusão 102. Mais uma vez, uma tal configuração pode ser desejável quando, por exemplo, somente uma máquina RFT e uma bomba de infusão estão ligadas ao paciente 110. Esta configuração pode eliminar a necessidade do monitor do paciente 106 se os sensores 108 puderem estar acoplados de forma comunicativa com a máquina RFT 104 e/ou com a bomba de infusão 102.

Modalidade do Motor de Integração

[0091] A Fig. 10 mostra um diagrama do motor de integração 160 de exemplo das Figuras 1 e 5 a 9, de acordo com modalidades exemplares da presente descrição. Como discutido acima, o motor de integração 160 pode ser incluído em qualquer um dos dispositivos médicos 102, 104 e 106, e/ou em qualquer uma das portas 112,114 e 116. Além disso, o motor de integração 160 pode ser distribuído através de mais de um dispositivo e/ou implementado em outros dispositivos, tal como um servidor. Deve ser apreciado que o motor de integração 160 descrito em conjunção com a Fig. 10 é somente uma modalidade e que outras modalidades podem incluir menos ou mais componentes.

[0092] Os componentes mostrados na Fig. 10 podem ser implementados como circuitos integrados de aplicação específica separados, implementados com um ou mais circuitos integrados de aplicação específica, e/ou definidos como instruções legíveis por computador, as quais quando executadas fazem com que um circuito e/ou umprocessador executem uma ou mais operações configuradas especialmente relacionadas com a recepção, agregação, integração, conversão, e/ou processamento dos dados 130, 140 e 150 (e derivativos dos mesmos) para a exibição em uma interface de usuário única.

[0093] O motor de integração 160 de exemplo inclui uma interface de bomba de infusão 1002 para receber os dados de progresso da terapia de infusão 130, uma interface de diálise 1004 para receber os dados de progresso da terapia de insuficiência renal 140, e uma interface de monitor 1006 para receber os dados fisiológicos 150. As interfaces 1002, 1004 e 1006 podem incluir APIs bem definidas configuradas para receber os dados de acordo com um formato definido. Como alternativa, as interfaces 1002, 1004 e/ou 1006 podem incluir interfaces web para receber, por exemplo, os dados 130,140 e 150 por meio de pacotes em um protocolo HTTP.

[0094] O motor de integração 160 pode incluir múltiplas versões de cada uma das interfaces 1002, 1004 e/ou 1006 (por exemplo, APIs diferentes) para a compatibilidade com os diferentes padrões de dados, protocolos, formatos, etc. Por exemplo, o motor de integração 160 pode incluir uma primeira interface de bomba de infusão 1002 para receber os dados de infusão associados com um primeiro padrão e uma segunda interface de bomba de infusão 1002 para receber os dados de infusão associados com um segundo padrão. A porta de infusão 112, por exemplo, pode ter portas bem definidas e/ou interfaces associadas com cada padrão que estão acopladas de forma comunicativa com as respectivas interfaces de bomba de infusão 1002 no motor de integração 160. Uma tal configuração automaticamente direciona os dados de progresso da terapia de infusão 130 de cada padrão para a interface de bomba de infusão 1002 apropriada. Deve ser apreciado que as portas 114 e 116 podem ser configuradas de maneira semelhante à porta de infusão 112.

[0095] Adicionalmente ou como alternativa, o motor de integração 160 pode incluir um roteador configurado para direcionar os dados de progresso da terapia de infusão 130 para a versão apropriada da interface de bomba de infusão 1002. Por exemplo, um roteador pode comparar o cabeçalho do pacote de dados, identificadores, ou outro indício (por exemplo, tipos de dados, rótulos, etc.) que são indicativos do padrão de uma ou mais tabelas de direcionamento. Uma tabela de direcionamento especifica para qual das interfaces 1002 os dados 130 devem ser direcionados com base em um padrão determinado. Responsivo à determinação do padrão, o roteador transmite os dados para a interface de bomba de infusão 1002 apropriada para a conversão para um formato comum. Deve ser apreciado que os roteadores também podem existir para as interfaces 1004 e 1006.

[0096] Os dados 130, 140 e 150, recebidos nas interfaces 1002, 1004 e/ou 1006 podem ser difundidos ou transmitidos periodicamente a partir das respectivas portas 112, 114 e 116, e/ou pelos dispositivos médicos 102, 104 e 106. Em alguns casos, as interfaces 1002, 1004 e 1006, podem ser configuradas para solicitar os dados 130, 140 e 150 a partir das respectivas portas 112, 114 e 116, e/ou dos dispositivos médicos 102, 104 e 106. Nestes casos, a solicitação pode incluir o identificador do paciente e/ou uma indicação de quais tipos de dados devem ser recebidos.

[0097] Para receber os dados 130, 140 e 150, o motor de integração 160 do exemplo inclui um subscritor 1007. O subscritor 1007 de exemplo é configurado para receber uma indicação de qual paciente está localizado adjacente a qual dispositivo médico. Por exemplo, se o motor de integração 160 está localizado na porta do monitor 116, o monitor do paciente 106 pode fornecer um identificador do paciente assim como um endereço MAC ou um endereço de IP. O endereço MAC ou de IP é utilizado pelo motor de integração 160 como um endereço de destino para os pacotes ou dados que são transmitidos para a exibição. O subscritor 1007 está configurado para transmitir o identificador do paciente para as portas 112 e 114 (em casos onde o motor 160 está na porta 116) para subscrever para os dados 130 e 140 que incluem o identificador do paciente. A subscrição faz com que as portas 112 e 114 transmitam quaisquer dos dados 130 e 140 com o critério específico para o motor de integração 160.

[0098] Como alternativa, a porta 116 (e o motor de integração 160) podem receber todos os dados provenientes das portas 112 e 114. Neste caso, o subscritor 1007 funciona com as interfaces 1002, 1004 e 1006, com o conversor 1008, e/ou o integrador de dados 1010 com o objetivo de selecionar quais dos dados devem ser processados e/ou exibidos. Em alguns desses casos, o subscritor 1007 pode fornecer o identificador do paciente para a porta de monitor 116, que filtra pelo identificador do paciente e transmite os dados filtrados para as interfaces 1002, 1004 e 1006.

[0099] O subscritor 1007 pode também subscrever para certos tipos de dados em adição aos dados relacionados com o paciente. Por exemplo, a configuração ou o setup no monitor 106 pode incluir a especificação de que todos os dados de taxa de infusão devam ser exibidos. O motor de integração 160 recebe essa informação de configuração por meio do configurador 1012, a qual é transmitida para o subscritor 1007. O subscritor 1007 de exemplo determina um ou mais parâmetros, rótulos de dados, e/ou identificadores de dados correspondentes associados com a taxa de infusão e transmite uma ou mais mensagens de subscrição para a porta de infusão 112, incluindo o identificador do paciente, e identificadores do parâmetro desejado (por exemplo, taxa de infusão, nome do medicamento, identificador da bomba, etc.). Isto faz com que a porta de infusão 112 apenas envie os dados relevantes que incluem os identificadores ou parâmetros especificados, deste modo reduzindo a quantidade de dados transmitida através do ambiente do hospital 100 e processado pelo motor de integração 160.

[0100] O subscritor 1007 de exemplo é dinâmico. Por exemplo, no decorrer de um tratamento, um clínico no monitor 106 pode especificar para também visualizar a dose da infusão. Isto faz com que a mensagem seja enviada a partir do monitor 106 para o motor de integração 160 (por meio do configurador 1012), que determina (por meio do subscritor 1007) um ou mais parâmetros de infusão (e o(s) identificador(es) correspondente(s)) associados com os dados da dose de infusão. O subscritor 1007, em seguida, envia a mensagem de subscrição para a porta de infusão 112 com os identificadores dos dados de dose desejada.

[0101] O motor de integração 160 de exemplo da Fig. 10 também inclui um conversor 1008 configurado para formatar, ou de outra maneira, converter os dados 130, 140 e 150, recebidos, para uma forma que seja compatível com o dispositivo que deve exibir os dados (por exemplo, o monitor do paciente 106). O conversor 1008 pode incluir interfaces ou módulos separados para receber dados de diferentes padrões provenientes de respectivas versões de interfaces 1002, 1004 e 1006. A conversão em cada módulo pode ser conduzida de acordo com uma rotina específica para a conversão de dados a partir de um padrão para um padrão comum ou normalizado. Por exemplo, um módulo para um primeiro padrão pode ter definições que relacionam rótulos do primeiro padrão a rótulos para um padrão comum. O módulo utiliza esse mapeamento um-para-um ou muitos-para-um para determinar como os dados devem ser convertidos.

[0102] Como alternativa, o motor de integração 160 pode incluir um de cada tipo de interface 1002, 1004 e 1006. Nessas modalidades alternativas, o conversor 1008 é configurado para determinar um padrão para os dados 130, 140 e 150, recebidos. O conversor 1008, em seguida, direciona os dados recebidos para cada padrão para o motor ou algoritmo de conversão de dados apropriado. Por exemplo, o conversor 1008 pode incluir um ou mais algoritmos de conversão bem definidos que especificam como os dados de certos formatos ou padrões, ou localizados em certas porções de um pacote devem ser analisados e reformatados para análise. Por exemplo, o algoritmo pode incluir uma tabela de consulta de nomes de parâmetro, rótulos, e/ou tipos de dados relacionados a diferentes dispositivos médicos conhecidos para permitir que o conversor 1008 determine os conteúdos dos dados. Deve ser apreciado que a tabela de consulta (ou algoritmos) pode fornecer uma conversão para cada padrão de dados suportado. Além disso, a tabela de consulta (ou algoritmos) pode ser atualizada periodicamente à medida que padrões adicionais são criados ou diferentes tipos de dispositivos médicos são adicionados ao ambiente 100.

[0103] O integrador de dados 1010 de exemplo na Fig. 10 é configurado para analisar os dados provenientes de diferentes interfaces 1002, 1004 e 1006 (e dados derivados das mesmas) e determinar quais dados devem ser exibidos simultaneamente. O integrador de dados 1010 pode acessar um banco de dados 1014 (por exemplo, uma memória) que fornece os critérios relativos a quais dados devem ser exibidos. Isto é especialmente verdadeiro em casos onde o motor de integração 160 recebe todos os dados 130, 140 e 150 para um paciente particular. Em casos onde somente, certos dados são subscritos, o integrador de dados 1010 de exemplo ainda tem de determinar quais dados são provenientes do mesmo período de tempo.

[0104] Em uma modalidade exemplar, o integrador de dados 1010 pode receber uma instrução que os dados para um paciente particular devem ser processados para a exibição. O integrador de dados acessa o banco de dados 1014 para uma lista de tipos de dados, parâmetros, ou identificadores de dados que devem ser exibidos. O integrador de dados 1010, em seguida, analisa ou, de outra maneira, filtra os dados para o paciente particular que incluem os identificadores específicos. O integrador de dados 1010 também lê os registros de tempo associados com cada dado para garantir dados provenientes do mesmo período de tempo ou quadro de tempo seja processado mais tarde posteriormente ao mesmo tempo para uma exibição simultânea. Em alguns casos, o integrador de dados 1010 pode agregar dados selecionados para o mesmo período de tempo em um ou mais pacotes tendo o mesmo registro de tempo.

[0105] O configurador 1212 de exemplo na Fig. 10 é configurado para definir as listas referentes a cada dado que deve ser exibido, por exemplo, no monitor 106. O configurador 1012 de exemplo pode fornecer uma interface ou operar através da interface do usuário 402 do monitor do paciente 106. O configurador 1012 pode incluir uma lista de parâmetros disponíveis ou tipos de dados que podem ser exibidos. A lista pode também incluir identificadores de todos os dispositivos médicos e sensores relacionados com o paciente. O configurador 1012 pode, de maneira dinâmica, atualizar a lista à medida que dispositivos adicionais sejam conectados, ou de outra maneira, associados com o paciente 110.

[0106] Em uma modalidade, um clínico pode configurar o monitor 106 antes que o tratamento tenha início. Neste caso, o configurador 1012 pode fornecer uma lista de parâmetros default para que o clínico selecione. O configurador 1012 pode, em seguida, determinar os parâmetros de dispositivo específicos ou o próprio dispositivo à medida que o dispositivo se mostre online e inicie a transmissão de dados. Neste caso, o configurador 1012 permite que o clínico selecione quais formas de onda devem ser exibidas e, em seguida, opere com o subscritor 1007 e com o integrador de dados 1010 para assegurar que os dados desejados serão exibidos. Se por exemplo, os dados não estão disponíveis, o motor de integração 160 pode fornecer uma mensagem de erro ou uma forma de onda nula (por exemplo, um clínico seleciona visualizar uma taxa de ultrafiltração de um RFT quando, na verdade, nenhum RFT ou máquina de diálise está conectado ao paciente 110).

[0107] Em uma outra modalidade, o configurador 1012 pode rastrear quais dispositivos estão associados com um identificador do paciente. O configurador 1012 pode determinar os parâmetros ou os tipos de dados de cada dispositivo e construir uma lista correspondente para que o clínico configure o monitor 106. Por exemplo, cada dispositivo médico pode transmitir um identificador de dispositivo em conjunto com o identificador do paciente ao ser associado com o paciente. O configurador 1012 recebe a mensagem e utiliza os identificadores de dispositivos para rastrear quais dispositivos estão conectados, ou de outra maneira, relacionados com o paciente 110.

[0108] O configurador 1012 também permite que um clínico ou um administrador crie uma ou mais rotinas ou algoritmos para processar e/ou criar derivativos dos dados 130, 140 e 150. Por exemplo, um administrador ou um clínico pode utilizar o configurador 1012 para definir um cálculo para a entrada de fluido total com base em quais dispositivos estão ligados ao paciente. O configurador 1012 pode fornecer uma interface programável gráfica que, por exemplo, mostre um mapa ou ilustração dos dispositivos associados com um paciente e os parâmetros correspondentes. O clínico pode arrastar, ou de outra forma, selecionar os parâmetros associados com a entrada de fluido proveniente de diferentes máquinas em uma equação, que cria uma rotina armazenada no banco de dados 1014. Um processador 1016 acessa a rotina no banco de dados 1014 para determinar quais e como os parâmetros devem ser somados.

[0109] Em outros casos, o banco de dados 1014 pode armazenar rotinas ou cálculos default para determinar os derivativos utilizados comumente dos dados 130, 140 e 150. Por exemplo, um cálculo default para o equilíbrio de fluidos pode especificar que os dados de taxa de infusão 130 são necessários em adição aos dados de saída e preenchimento de fluidos 140 e aos dados de urina 150. A seleção do cálculo de equilíbrio de fluidos pode fazer com que o configurador 1012 determine que os dados de taxa de infusão 130 são necessários em adição aos dados de saída e preenchimento de fluidos 140 e aos dados de urina 150 para a exibição e garantia de que os dispositivos apropriados estejam programados e ligados ao paciente 110. Durante o tratamento do paciente, o processador 1016 determina os valores para o equilíbrio de fluidos com base no cálculo utilizando os dados de taxa de infusão 130 em adição aos dados de saída e preenchimento de fluidos 140 e aos dados de urina 150, e fornece esses valores derivativos calculados para a exibição.

[0110] Como alternativa, um administrador pode definir rotinas default antes de quaisquer tratamentos de pacientes. O configurador 1012 pode popular as rotinas com base em quais dispositivos estão ligados ao paciente e/ou as preferências de um clínico. Por exemplo, um administrador pode criar por meio do configurador 1012 uma definição default de entrada de fluido, que pode especificar que uma taxa de infusão proveniente das bombas de infusão ligadas a um paciente é somada com o fluido de diálise fornecido em uma cavidade peritoneal do paciente em adição a qualquer informação recebida a partir de um sistema de alimentação nutricional. O configurador 1012 pode receber uma mensagem proveniente do monitor que indica que o clínico deseja visualizar o parâmetro de entrada de fluido, o que faz com que o configurador 1012 determine (se ainda não estiver completo) quais bombas de infusão, máquinas RFT, e sistemas de alimentação nutricional estão ligados ao paciente. O configurador 1012, em seguida, pesquisa pela taxa de infusão, taxa de diálise, e parâmetros de taxa de alimentação provenientes dessas máquinas e povoa a rotina apropriadamente.

[0111] O processador 1016 de exemplo na Fig. 1 é configurado para determinar quaisquer parâmetros ou derivativos dos dados 130, 140 e 150, com base em uma ou mais rotinas e/ou algoritmos armazenados no banco de dados 1014. O exemplar processador 1016, por exemplo, utiliza uma ou mais rotinas para determinar a entrada de fluido total para um paciente, uma saída de fluido total de um paciente, e um fluido total líquido no paciente. O processador 1016 executa a uma ou mais rotinas para cada caso ou registro de tempo dos dados 130, 140 e 150, integrados e convertidos.

[0112] O processador 1016 de exemplo pode também operar com o configurador 1012 para fornecer uma funcionalidade de interface de usuário com os dados. Por exemplo, o processador 1016 pode definir uma ou mais ações que podem ser executadas subordinadas à seleção, por um usuário, de uma porção de uma forma de onda exibida no monitor 106. Especificamente, o processador 1016 pode criar uma caixa de opção de menu que é escondida no visor até que um usuário selecione a forma de onda. A seleção de uma opção de menu pode alterar quais dados devem ser exibidos. O processador 1016 de exemplo e/ou o configurador 1012 atualiza a lista no banco de dados 1014 com a nova seleção do usuário, o que faz com que o integrador de dados 1010 possivelmente selecione mais ou menos dados para o processamento e faça com que o processador 1016 execute mais ou menos rotinas.

[0113] O processador 1016 pode também operar uma ou mais rotinas relacionadas a alarmes, alertas ou eventos. Por exemplo, o processador 1016 pode comparar dados especificados a limites ou tendências de dados a limites para determinar se um alerta ou evento deve ser gerado. O processador 1016 pode transmitir uma mensagem para o monitor 106 fazendo com que o alarme ou evento seja exibido. Deve ser apreciado que as rotinas possam ser complexas com a habilidade de levar em consideração os dados provenientes de uma grande variedade de dispositivos médicos. Por exemplo, certos limites de alarme podem ser ajustados com base na ocorrência de uma infusão ou diálise. Em outro caso, um alarme para um limite na quantidade de fluido disposta a um paciente pode ser atrasado sob a determinação de que uma máquina RFT estar prestes a iniciar uma fase de drenagem.

[0114] O processador 1016 de exemplo também formata os dados para a exibição, incluindo os dados de transmissão associados com o mesmo registro de tempo ao mesmo tempo (ou tão próximo quanto possível) para o monitor 106. O processador 1016 pode, além disso, formatar os dados para que sejam compatíveis com o monitor do paciente 106. Por exemplo, o processador 1016 pode fornecer indicações relativas a quais dados devem ser exibidos em certos locais da tela no monitor 106. O clínico pode fornecer a determinação inicial, que é incluída pelo processador 1016 em uma ou mais mensagens para o monitor 106. Como alternativa, o processador 1016 pode determinar a ordem com base na importância predeterminada dos diferentes parâmetros ou tipos de dados.

[0115] A interface de transmissão 1018 de exemplo do motor de integração 160 é configurada para transmitir os dados para a exibição na interface de usuário 402 do monitor do paciente 106, por exemplo. A transmissão pode incluir pacotes de dados. Como alternativa, a transmissão pode incluir um fluxo de dados. Em alguns casos, a interface de transmissão 1018 pode transmitir os dados periodicamente, tal como a cada 5 ou 10 segundos. Como alternativa, a interface de transmissão 1018 pode criar uma fila de dados até que uma mensagem de solicitação seja recebida proveniente do monitor do paciente 106.

[0116] Com base na descrição acima, deve ser apreciado que o motor de integração 160 melhora o desempenho do ambiente do hospital 100 ao, simultaneamente, processar milhares de partes de dados (em diferentes formatos) a partir de centenas ou milhares de dispositivos médicos tal que apenas dados específicos para um paciente particular são exibidos em uma interface de usuário única. O motor de integração 160 também inclui lógica, algoritmos, ou rotinas para determinar parâmetros, eventos, ou alarmes a partir dos dados recebidos e tornar esses parâmetros, eventos, e alarmes igualmente disponíveis para serem exibidos com a interface de usuário. Tais operações estão além das capacidades de um computador de uso geral operando funções genéricas ou gerais.

Fluxograma de Modalidade de Processamento de Dados de um Motor de Integração Exemplar

[0117] As Figuras 11 e 12 mostram um diagrama de fluxo que ilustra um procedimento exemplar 1100 para processar dados médicos provenientes de diferentes dispositivos médicos para a exibição em uma interface de usuário, de acordo com uma modalidade exemplar da presente descrição. O procedimento exemplar 1100 pode ser levado a efeito por, por exemplo, o motor de integração 160 descrito em conjunção com as Figuras 1 a 10. Embora o procedimento 1100 seja descrito com referência ao diagrama de fluxo ilustrado nas Figuras 11 e 12, deve ser apreciado que muitos outros métodos de execução das funções associadas com o procedimento 1100 podem ser utilizados. Por exemplo, a ordem de muitos dos blocos pode ser alterada, certos blocos podem ser combinados com outros blocos, e muitos dos blocos descritos são opcionais.

[0118] O procedimento 1100 inicia quando o motor de integração 160 recebe uma mensagem 1101 que inclui um identificador do paciente de um paciente que está se submetendo a um tratamento (bloco 1102). O motor de integração 160 também pode receber uma indicação relativa a quais dispositivos médicos estão associados com o identificador do paciente. Em alguns casos, o motor de integração 160 pode consultar algumas ou todas as portas 112, 114 e/ou 116, para determinar quais dispositivos médicos estão associados com o paciente. Nesses exemplos, os dispositivos médicos podem motivar um clínico a inserir um identificador do paciente ou a realizar a leitura de um código de barras associado com o paciente antes de programar ou iniciar o tratamento. Nesses exemplos, o identificador do paciente pode ser incluído em um cabeçalho de dados médicos. Adicionalmente ou como alternativa, o motor de integração 160 pode consultar o HIS 120 para a associação paciente-dispositivo. Nesses exemplos, o fluxo descendente do HIS 120 pode fazer a associação ou determinar a associação entre os dispositivos médicos e os pacientes.

[0119] O motor de integração 160, ao executar o procedimento 1100, pode também receber uma ou mais mensagens 1103 que indicam quais os dados médicos devem ser exibidos em um monitor do paciente (bloco 1104). As mensagens 1103 podem especificar um nome ou identificador de um parâmetro de dispositivo médico que corresponde a um valor numérico ou a uma forma de onda. Em alguns casos, o motor de integração 160 pode determinar os identificadores como especificado pela geração do dispositivo médico com base nos parâmetros ou entradas de nomes de parâmetro no monitor do paciente.

[0120] A Fig. 13 mostra um diagrama de uma configuração exemplar de uma interface de usuário 1300 que pode operar por meio do motor de integração 160 e exibir por meio do monitor do paciente 106, de acordo com uma modalidade exemplar da presente descrição. Neste exemplo, o motor de integração 160 determina quais dispositivos médicos estão associados com o paciente ABC123. Isto inclui a detecção de quais dispositivos médicos estão diretamente ou indiretamente ligados ao monitor 106, o que pode incluir um sensor de taxa cardíaca e/ou um sensor de pressão sanguínea. Nesse sentido, o motor de integração 160 faz com que o monitor do paciente 106 exiba ícones indicativos dos sensores conectados. Um usuário pode selecionar qualquer ou cada sensor, fazendo com que o motor de integração 160 determine as informações a respeito dos sensores (por exemplo, identificador, tipos de dados, padrão de dados, etc.) e se o sensor é configurável. Por exemplo, o motor de integração 160, através da interface de usuário 1300, pode permitir que um usuário selecione quais tipos de dados são produzidos por um sensor e/ou com que frequência os dados são transmitidos.

[0121] A interface de usuário 1300 de exemplo também exibe os dispositivos médicos que não estão conectados ao monitor 106, mas que foram determinadas a serem associadas com o paciente. No exemplo ilustrado, os dispositivos de paciente associados incluem a bomba de infusão SP9CY 102 e a máquina RFT peritoneal WSPEXQ 104. O motor de integração 160, através da apuração dos dispositivos (ou através das configurações que definem as bibliotecas), determina quais parâmetros de dados médicos são produzidos (ou selecionados para serem produzidos com base no tipo de terapia da seleção do clínico) por cada dispositivo. Por exemplo, a bomba de infusão devetransmitir os dados de progresso da terapia de taxa de infusão 130, os dados de progresso da terapia de dose de infusão 130, e os dados de progresso da terapia do volume a ser injetado (“VTBI”) 130. O motor de integração 160, através da interface de usuário 1300, permite que um clínico selecione quais dos dados devem ser exibidos no monitor 106 durante o tratamento. Em alguns exemplos, um clínico pode selecionar cada um dos parâmetros, fazendo com que o motor de integração 160 consulte o dispositivo médico para (ou de outra forma determine) a informação de operação. O motor de integração 160, através da interface de usuário 1300, em seguida, permite que um usuário altere os ajustes ou parâmetros da terapia, o que faz com que o motor de integração 160 envie uma ou mais mensagens para o dispositivo médico apropriado com as instruções de programação. Desta maneira, o motor de integração 160 permite que um clínico programe os dispositivos médicos conectados, ou de outra maneira, associados com um paciente a partir de um dispositivo, por exemplo, o monitor 106.

[0122] A interface de usuário 1300 de exemplo também inclui recursos que permitem a um clínico programar ou configurar alarmes e/ou dados derivados. A Fig. 14 mostra um diagrama de um exemplo de configuração de dados derivados na interface de usuário 1400 que pode ser operado pelo motor de integração 160 e exibido pelo monitor do paciente 106, de acordo com uma modalidade exemplar da presente diculgação. A seleção do ícone “Dados derivados” na interface de usuário 1300 pode fazer com que o motor de integração 160 exiba a interface de usuário 1400. O motor de integração 160, através da interface de usuário 1400, permite que um clínico selecione os dados derivados para exibir no monitor 106 e/ou crie um novo tipo de dados derivados com base no dispositivo médico. A interface de usuário 1400 inclui uma lista de dispositivos médicos relacionados com o paciente ABC123, que inclui uma bomba de infusão, uma máquina RFT, um sensor de taxa cardíaca, e um sensor de pressão sanguínea. A interface de usuário 1400 também inclui uma seção 1402 que exibe quais dados médicos estão disponíveis a partir dos dispositivos médicos.

[0123] A interface de usuário 1400 de exemplo também exibe uma seção de definição 1404 que é configurada para especificar como os dados derivados dão derivados. Em alguns casos, a definição pode ser predefinida ou pré-especificada. Por exemplo, a interface de usuário 1400 pode incluir uma seção (não mostrada) de tipos disponíveis de dados derivados com base nos tipos disponíveis de dados médicos. Para determinar os tipos de dados derivados disponíveis, o motor de integração 160 pode comparar os tipos disponíveis de dados médicos na seção 1402 a uma lista de dados derivados que identifica todas as variáveis de dados médicos necessários para estarem disponíveis para permitir que os dados derivados sejam determinados. Em alguns casos, um clínico pode selecionar certos dados derivados, e o motor de integração 160 pode fornecer uma indicação relativa a quais dados médicos ainda são necessários. Uma tal indicação pode ser fornecida como uma instrução ou um lembrete para um clínico a respeito de dispositivos adicionais que precisam ser conectados ou associados com o paciente.

[0124] No exemplo ilustrado da Fig. 14, a interface de usuário 1400 dentro da seção 1404 é configurada para permitir que um clínico crie graficamente os dados derivados. Por exemplo, a interface de usuário 1400, por meio do motor de integração 160, permite que um clínico selecione e arraste dados médicos para a seção 1404, o que cria uma representação gráfica. A interface de usuário 1400 também permite que o clínico selecione operações a partir da seção 1406 para especificar um relacionamento entre os dados. Uma tal configuração programa, de modo especial, o motor de integração 160 para determinar os dados derivados com a utilização de uma rotina especificada graficamente pelo clínico. Neste exemplo, um clínico especifica como os dados derivados de equilíbrio de fluidos são determinados a partir de uma combinação dos dados da terapia de infusão 130 e dos dados RFT 140. Deve ser apreciado que o motor de integração 160 pode fornecer uma interface semelhante para facilitar a especificação das condições/limiares para alarmes e/ou alertas.

[0125] Retornando à Fig. 11, após a configuração e/ou seleção dos dados, o motor de integração 160 utiliza o identificador do paciente e/ou os dados médicos para subscrever ou, de outra forma, receber ou filtrar os dados médicos identificados associados com o identificador do paciente (bloco 1106). Por exemplo, o motor de integração 160 pode transmitir uma ou mais mensagens 1107 para a porta 112, 114 e/ou 116 apropriada com o objetivo de receber os dados médicos solicitados ou selecionados 130, 140 e/ou 150. As mensagens 1107 podem incluir um endereço de IP ou outro endereço/identificador/número de interface d porta associado com o motor de integração 160. As mensagens 1107 podem também incluir um identificador ou rótulo de dados dos dados médicos solicitados.

[0126] O motor de integração 160, em seguida, recebe os dados médicos provenientes dos dispositivos médicos (bloco 1108). Os dados médicos podem ser recebidos dentro de uma ou mais mensagens e/ou pacotes 1109 provenientes, por exemplo, das portas 112, 114, 116, e/ou do monitor do paciente 106. O motor de integração 160 pode determinar quais dos dados estão associados com o paciente e/ou parâmetros identificados (bloco 1110). Por exemplo, o motor de integração 160 pode gerenciar o processamento dos dados médicos para centenas de pacientes, cada um dos quais associados com dois ou mais dispositivos médicos produzindo pelo menos um parâmetro de dados médicos ou dados de progresso de terapia. Em outras palavras, o motor de integração 160 pode subscrever para uma quantidade significante de dados médicos que precisam ser organizados por paciente, dispositivo médico, parâmetro, registro de tempo, etc. Deve ser apreciado que esta etapa pode ser omitida quando o motor de integração 160 é configurado para subscrever ou receber dados médicos relacionados a apenas um paciente.

[0127] O motor de integração 160 determina quais dos dados identificados devem ser exibidos com base nas mensagens 1103 recebidas previamente no bloco 1104 (bloco 1112). O motor de integração 160 determina se uma ou mais rotinas ou algoritmos devem ser operadas para processar adicionalmente os dados médicos com o objetivo de determinar os dados derivados (bloco 1114). Por exemplo, se o motor de integração 160 determina que a entrada de fluido total, a saída de fluido total, e os parâmetros de fluido líquidos devem ser determinados e exibidos no monitor, o motor de integração 160 opera as rotinas associadas para determinar esses parâmetros (bloco 1116). O motor de integração 160 pode, em seguida, converter os dados médicos para exibir em um formato que seja compatível com o monitor do paciente (bloco 1118). Em alguns exemplos, esta etapa pode, em vez disso, ser realizada após a recepção dos dados médicos provenientes dos dispositivos médicos. O motor de integração 160, em seguida, transmite os dados médicos para o monitor do paciente para a visualização (bloco 1120). Deve ser apreciado que os blocos 1108 e 1120 podem estar em ciclo continuamente por tanto tempo quanto o paciente esteja se submetendo ao tratamento e/ou até que todos os dispositivos médicos tenham sido desativados ou dissociados do paciente. Neste ponto, o procedimento exemplar 1100 finaliza, com respeito ao monitoramento do paciente.

Modalidade de Conversão de Dados

[0128] Como discutido acima, o exemplo de motor de integração 160 das Figuras 1 e de 5 a 12 é configurado para converter, ou de outra forma, converter dados médicos 130 e 140 a partir de um padrão, formato, linguagem, ou protocolo para um outro padrão, formato, linguagem, ou protocolo que seja compatível com o HIS 120 ou um outro dispositivo médico. A Fig. 15 mostra um diagrama de conversão de dados fornecido por um ou mais motores de integração 160 dentro do exemplar ambiente de hospital 100 da Fig. 1, de acordo com modalidades exemplares da presente descrição. No exemplo ilustrado, uma porta de infusão 112 inclui um primeiro motor de integração 160a, a porta RFT 114 inclui um segundo motor de integração 160b, e o monitor do paciente 106 inclui um terceiro motor de integração 160c (a porta de monitor 116 é omitida). No entanto, em algumas modalidades alternativas, a porta de monitor 116 pode ser incluída com o ambiente 100 e operando o motor de integração 160c.

[0129] No exemplo da Fig. 15, a bomba de infusão 102 e a máquina RFT 104 são configuradas para operar utilizando o protocolo EXTCOM (por exemplo, um protocolo de comunicação proprietário da Baxter®). O monitor do paciente 106 é configurado para operar com a utilização do protocolo Health Level 7 (“HL7”). Em sistemas de hospitais conhecidos, a bomba de infusão 102 e a máquina RFT 104 não seriam capazes de se comunicar com o monitor do paciente 106 devido à utilização de protocolos diferentes.

[0130] O protocolo EXTCOM utiliza uma sintaxe de codificação de Linguagem de Marcação Extensível (“XML”) que inclui um cabeçalho, um corpo, e uma seção de identificador de código. O cabeçalho inclui campos que especificam, por exemplo, uma versão do protocolo EXTCOM, número de série do dispositivo de transmissão, endereço de destino, registro de tempo da mensagem, identificador de mensagem único, um tipo de mensagem EXTCOM, uma bandeira de criptografia, e um código de autenticação. O cabeçalho pode também especificar um dispositivo identificador EMR para a configuração com, por exemplo, o HIS 120. O tipo de mensagem pode incluir umm status da mensagem, uma mensagem de configuração, uma mensagem de definição, uma mensagem de biblioteca de medicamentos, uma mensagem de consulta da bomba, ou uma mensagem de ordem de infusão.

[0131] O protocolo HL7 também inclui uma sintaxe de codificação XML. Algumas porções do protocolo HL7 incluem cabeçalhos de mensagem que são semelhantes aos do protocolo EXTCOM, incluindo uma versão do protocolo, um número de série do dispositivo de transmissão, endereço de destino, registro de tempo da mensagem, identificador de mensagem único. No entanto, o protocolo HL7 utiliza rótulos diferentes para os campos do cabeçalho em comparação com o protocolo EXTCOM. Além disso, o protocolo HL7 pode incluir campos de cabeçalho adicionais incluindo um identificador de interação, um código de processamento, um identificador de tipo de dispositivo, um identificador de localização do dispositivo de transmissão, e um identificador de localização do dispositivo de recepção.

[0132] A máquina RFT 104 e a bomba de infusão 102 são configuradas para receber e processar mensagens EXTCOM. Isto significa que a máquina RFT 104 e a bomba de infusão 102 são programadas para pesquisar por informações no cabeçalho e no corpo utilizando certos rótulos para identificar os campos. A utilização de diferentes rótulos e estruturas de mensagens torna difícil, se não impossível, para que a máquina RFT 104 e a bomba de infusão 102 recebam e processem as mensagens HL7.

[0133] Para superar essas limitações, o primeiro motor de integração 160a é configurado para converter os dados transmitidos para a bomba de infusão 102 para o protocolo EXTCOM. O primeiro motor de integração 160a é também configurado para converter os dados recebidos da bomba de infusão 102 para o protocolo HL7. De modo semelhante, o segundo motor de integração 160b é configurado para converter os dados transmitidos para a máquina RFT 104 para o protocolo EXTCOM. O segundo motor de integração 160b é também configurado para converter os dados recebidos da máquina RFT 104 para o protocolo HL7. O terceiro motor de integração 160c é configurado para receber e exibir os dados 130 e 140 provenientes dos respectivos dispositivos médicos 102 e 104 no protocolo HL7. Em alguns exemplos, os motores de integração 160a e 160b podem ser integrados com o motor de integração 160c no monitor do paciente 106 e/ou na porta do monitor 116.

[0134] No exemplo ilustrado mostrado na Fig. 15, a bomba de infusão 102 (no decorrer do tratamento do paciente 110) transmite os dados de progresso da terapia de infusão 130a formatados no protocolo EXTCOM para a porta de infusão 112. O primeiro motor de integração 160a converte os dados 130a a partir do protocolo EXTCOM para o protocolo HL7. O primeiro motor de integração 160a, em seguida, transmite os dados convertidos 130b para o monitor do paciente 106 para a exibição. Para executar a conversão, o primeiro motor de integração 160a pode incluir instruções que especificam como certos rótulos EXTCOM devem ser traduzidos para os rótulos HL7. As instruções também podem especificar a ordem ou o posicionamento dos campos dentro da mensagem HL7. As instruções podem, além disso, especificar informações adicionais a serem adicionadas à mensagem HL7 (se conhecidas) ou informações default que são fornecidas para garantir que a mensagem HL7 será verificada como sendo autêntica. Em alguns casos, as instruções podem também fornecer para unidade de conversão a partir de um primeiro tipo de unidade utilizado para EXTCOM para um segundo tipo de unidade utilizado para HL7. Além disso, as instruções no motor de integração 160a podem também fornecer uma tradução dos nomes dos medicamentos (ou abreviações) utilizados no protocolo EXTCOM para corresponder aos nomes de medicamentos (ou abreviações) utilizados no protocolo HL7.

[0135] Também no exemplo ilustrado, a máquina RFT 104 transmite os dados de progresso da terapia de falah renal 140a que são formatados no protocolo EXTCOM para a porta RFT 114. O segundo motor de integração 160b converte os dados 140a a partir do protocolo EXTCOM para o protocolo HL7. O segundo motor de integração 160b, em seguida, transmite os dados convertidos 140b para o monitor do paciente 106 para a exibição. O motor de integração 160c recebe os dados 130b e 140b no formato HL7 e determina se dados derivados precisam ser determinados. O motor de integração 160c também faz com que o monitor do paciente exiba os dados 130b e 140b. Em alguns casos, o motor de integração 160c pode ser configurado para converter os dados 130b e 140b em um outro protocolo que seja compatível com o monitor do paciente 106 antes que os dados possam see exibidos.

Conclusão

[0136] Será apreciado que todos os métodos divulgados e procedimentos descritos neste documento possam ser implementados com a utilização de um ou mais componentes ou programas de computador. Esses componentes podem ser fornecidos como uma série de instruções de computador ou qualquer meio convencional legível por computador, incluindo RAM, ROM, memória flash, discos óticos ou magnéticos, memória ótica, ou outros meios de armazenamento. As instruções podem ser configuradas para serem executadas por um processador, o qual quando executa a série de instruções de computador realiza ou facilita o desempenho de todo ou parte dos métodos e procedimentos divulgados.

[0137] Deve ser entendido que várias alterações e modificações às modalidades exemplares descritas neste documento serão aparentes àqueles hábeis na tecnologia. Tais alterações e modificações podem ser feitas sem que se separe do espírito e escopo da presente matéria e sem que se diminuam as vantagens pretendidas. É, por essa razão, pretendido que tais alterações e modificações sejam cobertas pelas reivindicações em anexo.

[0138] Seria apreciado que 35 U.S.C. 112(f) ou pre-AIA 35 U.S.C. 112, parágrafo 6 não seja pretendida a ser invocada a não ser que os termos “meios” ou “etapa” sejam explicitamente recitados nas reivindicações. Neste sentido, as reivindicações não se destinam a ser limitadas às correspondentes estrutura, material, ou ações descritas nas especificações ou equivalentes das mesmas.

Claims

1. Sistema de tratamento de saúde em rede (100) que compreende: uma máquina de terapia de insuficiência renal (104) acoplada de forma comunicativa a um sistema de informação hospitalar (120, 122) configurada para: realizar um tratamento de terapia de insuficiência renal para um paciente, determinar pelo menos um parâmetro de terapia de insuficiência renal relacionado com o tratamento de terapia de insuficiência renal que inclui uma taxa de ultrafiltragem na qual um fluido é removido do paciente, determinar um registro de tempo da terapia de insuficiência renal para o pelo menos um parâmetro de terapia de insuficiência renal, e transmitir o pelo menos um parâmetro de terapia de insuficiência renal, um identificador de paciente do paciente, e o registro de tempo da terapia de insuficiência renal para o sistema de informação hospitalar (120, 122); uma bomba de infusão (102) acoplada de forma comunicativa ao sistema de informação hospitalar (120, 122) configurada para: realizar um tratamento de infusão para o mesmo paciente simultaneamente com a máquina de terapia de insuficiência renal (104), determinar pelo menos um parâmetro de infusão relacionado com o tratamento de infusão que inclui uma taxa de infusão na qual um fluido é injetado no paciente, determinar um registro de tempo de infusão para o pelo menos um parâmetro de infusão, e transmitir o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo de infusão para o sistema de informação hospitalar; um monitor (106) associado com o paciente e acoplado de forma comunicativa com o sistema de informação hospitalar (120, 122), o monitor configurado para: receber o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal, receber o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo de infusão, e determinar o pelo menos um parâmetro de terapia de insuficiência renal e o pelo menos um parâmetro de infusão que devem ser exibidos na combinação de interface de usuário (402) com base no identificador do paciente, caracterizado pelo fato de que o monitor (106) é configurado para: determinar um parâmetro de diferença com base em uma diferença entre o pelo menos um parâmetro de infusão e o pelo menos um parâmetro de terapia de insuficiência renal, exibir, na combinação de interface de usuário (402), o pelo menos um parâmetro de terapia de insuficiência renal dentro de uma linha de tempo de terapia de insuficiência renal, exibir, na combinação de interface de usuário (402), o pelo menos um parâmetro de infusão dentro de uma linha de tempo de infusão que é alinhado com a linha de tempo de terapia de insuficiência renal, e exibir, na combinação de interface de usuário (402), o parâmetro de diferença dentro de uma linha de tempo de diferença que é alinhado com a linha de tempo de terapia de insuficiência renal e com a linha de tempo de infusão.

2. Sistema (100), de acordo com a reivindicação 1, caracterizado por ainda compreender um motor de porta de monitor (116) configurado para: receber o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal a partir da máquina de terapia de insuficiência renal (104); receber o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo de infusão a partir da bomba de infusão (102); determinar o monitor (106) dentre uma pluralidade de monitores que está associado com o identificador do paciente; transmitir o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal para o monitor (106) determinado; e transmitir o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo de infusão para o monitor determinado (106).

3. Sistema (100), de acordo com a reivindicação 2, caracterizado por ainda compreender um motor de porta de terapia de insuficiência renal (114) configurado para: receber o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal a partir da máquina de terapia de falha renal (104); determinar que o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal devem ser transmitidos para o motor de porta do monitor (116); e transmitir o pelo menos um parâmetro de terapia de insuficiência renal, o identificador do paciente, e o registro de tempo da terapia de insuficiência renal para o motor de porta do monitor (116).

4. Sistema (100) de acordo com a reivindicação 2 ou 3, caracterizado por ainda compreender um motor de porta de infusão (112) configurado para: receber o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo de infusão a partir da bomba de infusão (102); determinar que o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo de infusão devem ser transmitidos para o motor de porta do monitor (116); e transmitir o pelo menos um parâmetro de infusão, o identificador do paciente, e o registro de tempo de infusão para o motor de porta do monitor (116).

5. Sistema (100), de acordo com qualquer uma das reivindicações 2 a 4, caracterizado por o monitor (106) ser um monitor de sinais vitais acoplado de forma comunicativa a um sensor fisiológico e configurado para: receber o pelo menos um parâmetro fisiológico a partir do sensor fisiológico (108); e exibir, na combinação de interface de usuário (402), o pelo menos um parâmetro fisiológico dentro de uma linha de tempo fisiológico que é alinhado com a linha de tempo de terapia de insuficiência renal e com a linha de tempo de infusão.

6. Sistema (100), de acordo com a reivindicação 5, caracterizado por o monitor de sinais vitais (106) ser configurado para transmitir o pelo menos um parâmetro fisiológico para pelo menos uma dentre a máquina de terapia de insuficiência renal (104) ou a bomba de infusão (102) por meio do motor de porta do monitor (116).

7. Sistema (100), de acordo com a reivindicação 1, caracterizado por o monitor (106) ser configurado para exibir o pelo menos um parâmetro de terapia de insuficiência renal, o pelo menos um parâmetro de infusão, e o parâmetro de diferença como um valor numérico adjacente à linha de tempo respectiva.

8. Sistema (100), de acordo com a reivindicação 1, caracterizado por a bomba de infusão (102) ser uma primeira bomba de infusão, o parâmetro de infusão ser um primeiro parâmetro de infusão, e o registro de tempo de infusão ser um primeiro registro de tempo de infusão, e ainda compreender uma segunda bomba de infusão acoplada de forma comunicativa ao sistema de informação hospitalar (120, 122), a segunda bomba de infusão configurada para: realizar um segundo tratamento de infusão para o mesmo paciente simultaneamente com a primeira bomba de infusão; determinar o pelo menos um segundo parâmetro de infusão relacionado com o segundo tratamento de infusão que inclui uma segunda taxa de infusão na qual um segundo fluido é injetado no paciente; determinar um segundo registro de tempo de infusão para o pelo menos um segundo parâmetro de infusão; e transmitir o pelo menos um segundo parâmetro de infusão, o identificador do paciente, e o segundo registro de tempo de infusão para o sistema de informação hospitalar (120, 122), e em que o monitor (106) é ainda configurado para receber o pelo menos um segundo parâmetro de infusão, o identificador do paciente, e o segundo registro de tempo de infusão, determinar o parâmetro de diferença com base na diferença entre o pelo menos um primeiro parâmetro de infusão, o pelo menos um segundo parâmetro de infusão, e o pelo menos um parâmetro de terapia de insuficiência renal, determinar se mais do que um tratamento de infusão está sendo fornecido para o paciente, exibir, na combinação de interface de usuário (402), o pelo menos um segundo parâmetro de infusão dentro de uma segunda linha de tempo de infusão que é alinhado com a linha de tempo de infusão, e exibir, na combinação de interface de usuário (402), um primeiro nome do fluido injetado por meio da primeira bomba de infusão adjacente à primeira linha de tempo de infusão e um segundo nome de um segundo fluido injetado por meio de uma segunda bomba de infusão adjacente à segunda linha de tempo de infusão.

9. Sistema (100), de acordo com a reivindicação 1, caracterizado por o pelo menos um parâmetro de diferença incluir uma quantidade líquida de troca de fluido dentro do paciente por um período de tempo.

10. Sistema (100), de acordo com a reivindicação 1, caracterizado por o pelo menos um parâmetro de terapia de insuficiência renal incluir uma taxa na qual o fluido é adicionado para o paciente a partir da máquina de terapia de insuficiência renal (104), uma quantidade total de fluido removido do paciente, uma quantidade de tempo restante para o tratamento de terapia de insuficiência renal, ou um evento associado com o tratamento de terapia de insuficiência renal.

11. Sistema (100), de acordo com a reivindicação 1, caracterizado por o pelo menos um parâmetro de infusão incluir um registro de tempo, um nome de medicamento do fluido injetado no paciente, uma quantidade total de fluido injetado no paciente, uma quantidade de tempo restante para o tratamento de infusão, um evento associado com o tratamento de infusão, ou um limite de medicamento para o tratamento de infusão.

12. Sistema (100), de acordo com a reivindicação 1, caracterizado por o pelo menos um do pelo menos um parâmetro de terapia de insuficiência renal e do pelo menos um parâmetro de infusão ser convertido para se adequar a um protocolo Health Level 7 (“HL7”) antes de ser exibido pelo monitor (106).