Resumo Quedas de pacientes hospitalizados causam mortalidade e morbidade. Os riscos nas instituições devem ser identificados e eliminados para prevenir quedas devido principalmente a motivos ambientais. Outros fatores de risco como marcha instável e condições incapacitantes também devem ser devidamente avaliados e tratados para evitar quedas relacionadas a medicamentos. Para tanto, duas escalas de risco de quedas, amplamente discutidas na literatura internacional, foram adotadas no Brasil: a Morse Fall Scale e a Johns Hopkins Fall Risk Assessment Tool (JH-FRAT). Neste estudo, optou-se por utilizar a escala JH-FRAT como instrumento cuja validade de conteúdo já foi testada, apresentando boa aplicabilidade em protocolos sistematizados e de simples operação. Foi utilizada a SNOMED-CT para representar e desambiguar os conceitos voltados às características pessoais e ambientais relacionadas ao risco de queda capturados pelos prontuários eletrônicos. Foram utilizadas construções de linguagem fornecidas pela ontologia OWL- TIME. Foi utilizada a Semantic Web Rule Language (SWRL) para calcular a pontuação da escala JH-FRAT. Os resultados obtidos demonstraram que a SWRL pretende ser a linguagem de regras da Web Semântica, baseandose em OWL e todas as regras são expressas em termos de conceitos OWL (classes, propriedades, indivíduos, literais, etc), assim como na SNOMED-CT, para representar conceitos relacionados ao risco de queda. Conclui-se que vários aspectos da classificação de risco de quedas são temporais, como a avaliação, evento de queda, tempo de jejum, entre outros. Para tanto, foi incorporada a ontologia OWL-Time e armazena as datas/horas no formato Unix-Time para facilitar seu uso nas regras SWRL.
As quedas de pacientes hospitalizados são causa de substanciais taxas de mortalidade e morbidade
[
As quedas de pacientes hospitalizados trazem consequências tanto para os pacientes quanto para as instituições de saúde. Portanto, foram criadas escalas que identificam condições de risco para a ocorrência de quedas, seja na forma de riscos específicos ou da estratificação de risco. Elas garantem que as intervenções diretas sejam compatíveis com as necessidades identificadas. A escala de risco Johns Hopkins Fall Risk Assessment Tool (JH-FRAT), amplamente discutida na literatura internacional, já foi adotada no Brasil [4]. Os aspectos considerados na avaliação do risco de queda por essa escala são, de uma forma ou de outra, captados e registrados no Prontuário Eletrônico do Paciente (PEP). Assim é possível a criação de programas e aplicativos para calcular automaticamente o risco de queda de pacientes internados. Uma maneira de se implementar um aplicativo deste tipo, é usar tecnologias da Web Semântica para representar tanto os conhecimentos e regras, contidos na escala de avaliação de queda, como os dados dos pacientes usando-se ontologias. Classes, propriedades, instâncias e regras de ontologias podem ser processadas por computadores, através de raciocinadores digitais (os reasoners) para derivar novos conhecimentos. A área da saúde é rica em ontologias, terminologias e vocabulários médicos controlados. Assim, é possível o reuso de terminologias como a Classificação Estatística Internacional de Doenças e Problemas Relacionados à Saúde (CID) que fornece códigos para a classificação de doenças, sinais, sintomas, aspectos anormais, circunstâncias sociais, ambientais e externas que refletem na condição de saúde de um indivíduo. Assim como a Nomenclatura Sistematizada de Medicina - Termos Clínicos (SNOMED CT) na qual se busca codificar a informação disponibilizada no prontuário do paciente para uma representação padronizada dos dados disponibilizados tanto em relação aos termos como em relação a um código único identificador daquele termo visando representar os dados disponibilizados [6].
Uma ontologia para cálculo de risco de queda de pacientes foi criada [8]. Nela utilizamos o SNOMED-CT para representar e desambiguar os conceitos relacionados às características pessoais e ambientais relacionadas ao risco de queda, capturados pelos prontuários eletrônicos. A escala JH-FRAT também é usada como instrumento, sua validade de conteúdo já foi testada, demonstrando boa aplicabilidade em protocolos sistematizados, além de possuir uma simples utilização [5]. Representar tempo em ontologias é uma questão complexa [7]. Por essa razão, na ontologia, informações temporais são representadas usando a ontologia OWL-TIME [9]. Finalmente, a Semantic Web Rule Language (SWRL) é usada para calcular a pontuação da escala JH- FRAT. Ela é usada para expressar as regras em termos de conceitos OWL (classes, propriedades, indivíduos, literais, etc.) [10].
O objetivo deste trabalho é criar e avaliar uma aplicação, baseada na ontologia de risco de queda e outras tecnologias da web semântica, para calcular o risco de quedas em pacientes hospitalizados. Ela está sendo testada pela equipe de enfermagem de um grande hospital em São Paulo, por parceiros usando-se um teste de usabilidade. Até o momento duas enfermeiras participaram dos testes. Elas consideraram que a ferramenta diminuiu o tempo de preenchimento dos dados além de avisar sobre riscos de queda já no momento da admissão do paciente.
Além de destacar os fatores de risco relacionados às quedas, a ontologia proposta possui informações
para calcular as respectivas pontuações e classificar o grau de risco de queda do paciente baseado na
escala JH-FRAT. Essa escala é composta por 8 aspectos de risco de queda: situações anteriores
relacionadas a queda; idade de admissão; se houve uma queda nos últimos seis meses; eliminação;
intestino e urina; uso de medicamentos com alto risco de queda; presença de equipamentos assistenciais
que possam comprometer a mobilidade do paciente; deficiência de mobilidade; prejuízo na cognição.
Para se avaliar o risco de queda de um paciente, é realizado uma soma por meio da análise individual
de cada tópico relacionado aos oito aspectos de risco que compõem a escala JH-FRAT, da qual ao final
da análise, é possível obter uma pontuação (sendo o máximo de 35 pontos), que é classificada em baixo
risco (até 5 pontos), risco moderado (de 6 a 13 pontos) e alto risco (acima de 13 pontos) [
Figura 1: Classificação de avaliação de risco de queda
Quando uma avaliação é realizada, ela deve ser inserida como uma instância da classe Avaliação de risco de queda. Assim como esta avaliação deve ser declarada como uma instância de time:Instant e a data de criação deve ser inserida na propriedade (time:inXSDDateTime) datetime:Instant individual. Vincular esta time:Instant para um indivíduo de time:TimePosition via time:inTimePosition, e o Unix Time da data de criação da avaliação em time:numericPosition. O paciente se relaciona com a avaliação pela propriedade temAvaliaçãoRiscoQueda. Para cada evento de queda, é criado uma instância das classes Queda e Instant, os eventos de queda estão relacionados à avaliação por temEventoQueda. A data é inserida em um formato de data e hora usando inXSDDateTimeStamp e a hora Unix dessa data no indivíduo correspondente em TimePosition, usando numericPosition.
Um fator determinante para o risco de queda é o procedimento de jejum do paciente, representado por um indivíduo pertencente a Jejum e ProperInterval, ligado à avaliação por temProcedimentoJejum ou éProcedimentoJejumDe. O indivíduo ProperInterval refere-se a dois indivíduos da classe Instant: hasBeginning e hasEnd. O intervalo hasBeginning é um indivíduo que armazena a data/hora de início rápido nos formatos de data e hora (Instant) e Unix Time (Time Position). O intervalo hasEnd é um indivíduo que armazena a data/hora do término do jejum nos formatos data-hora (Instant) e Unix Time (TimePosition). Os auxiliares de mobilidade estão significativamente associados a quedas, para cada dispositivo médico utilizado pelo paciente é criado um indivíduo pertencente às seguintes classes: Equipamentos Biomédicos; Dispositivos Biomédicos; e Dispositivos Assistivos. Os dispositivos são conectados à avaliação usando temDispositivoMédico. Outro fator de risco para quedas é o número de medicações concomitantes tomadas pelo paciente. O risco de queda tende a aumentar quando se toma medicamentos psicotrópicos ou anti coagulantes. Esses medicamentos são classificados como instâncias da classe 'agente do sistema nervoso central'. Os medicamentos são ligados à avaliação usando a propriedade temDrogaOuMedicamento. Ainda em relação ao uso de medicamentos, quando o paciente é operado com sedação, é criado uma instância da classe 'Administração de anestesia E/OU sedação', declarado como instância de Instant e a data e hora é colocada na propriedade inXSDDateTime. Usando inTimePosition, vincula Instant a um TimePosition individual, que armazena o Unix Time em numericPosition. A avaliação está relacionada ao procedimento de sedação por meio de temProcedimentoSedação. 2.1.
A ferramenta de avaliação tem uma interface de usuário, que pode rodar num tablet ou smartphone, e um servidor que implementa uma Application Programming Interface (API) consumida pela implementação da interface. O framework Flask foi utilizado para criar essa API e também o pacote Owlready2 para manipular a ontologia utilizando seu arquivo na extensão owl. A API espera como entrada um body JavaScript Object Notation (JSON), com os dados desejados de acordo com o protocolo descrito na ferramenta Swagger, que fornece uma visão dos comportamentos e atributos de uma API. A API Avaliação Risco Queda é responsável por usar as funções de manipulação da ontologia da biblioteca Owlready2, como executar queries SPARQL e ativar o Pellet reasoner. Com isso, é possível acessar totalmente as regras e inferências da ontologia e retornar o resultado como resposta da API.
Para fornecer uma aplicação que possa acessar e manipular a ontologia de avaliação de risco de queda, um aplicativo foi construído para atuar como um middleware entre as entradas de avaliação e o banco de dados. A camada de aplicação fornece as funcionalidades que permitem a inserção, transformação e recuperação de informações, para permitir, a partir da inclusão de dados brutos de uma avaliação de risco a ser processada, as transformações necessárias nos níveis de conversão de bases e dados, e a recuperação de informações da ontologia para apresentação dos resultados de pontuação. Para que essas funcionalidades pudessem estar disponíveis para consumo em outras aplicações e proporcionar interoperabilidade, definida como a capacidade de servidores de diferentes plataformas de software ou linguagens poderem se comunicar por meio de mediadores que convertem diferentes formatos de dados. O aplicativo foi estruturado internamente em camadas distintas e provisionado por meio do protocolo REST. O protocolo REST é uma alternativa às tecnologias de chamada de procedimento remoto baseado em SOAP. A aplicação foi construída utilizando a linguagem Python e o framework FLASK. Para a camada de inserção, foi construída uma classe que representa os dados brutos de entrada, simplificando a comunicação. Na camada de transformação, algumas transformações de base de dados e hora são realizadas, devido à dificuldade encontrada nos tempos de processamento com SWRL, onde a decisão escolhida foi trabalhar com tempos na forma UNIX TIME, mas o tipo primitivo para armazenar o inteiro no built-in matemático não permitia extensão completa do número UNIX TIME em alguns casos (bug). Para contornar essa situação, o algoritmo divide o número por 100 antes de armazenar, devido ao cálculo comparativo, durante este procedimento, não houve perda de informações. Na camada de recuperação de informações, os dados são armazenados, processados e recuperados de uma ontologia escrita com o padrão RDF. Para a utilização do SPARQL na aplicação, foi utilizado o Owlready2, sendo um pacote para programação orientada a ontologias em Python com capacidade de carregar ontologias OWL 2.0 como objetos Python, permitindo que ontologias sejam modificadas, salvas e utilizadas para fins de raciocínio. A importância desta biblioteca para a aplicação está na possibilidade de utilizar tanto o SPARQL quanto um REASONER, uma funcionalidade que processa as regras dos axiomas injetados na ontologia e resulta em informações computadas e expostas dinamicamente.
A ontologia criada neste trabalho foi baseada na estrutura de Avaliação de Risco de Queda, que contém itens e suas pontuações. Além disso, a avaliação possui uma classificação final, composta por três grupos: baixo, moderado e alto risco para queda, que é o resultado da soma de todas as notas obtidas na avaliação.
A ontologia é composta pelos itens de Avaliação de Risco de Queda e, para cada item, é atribuída uma pontuação para que possa ser utilizada na classificação final. Para atribuir essas pontuações, foi criada uma annotation property: pontos. Para a pontuação final, resultado da soma de todas as outras pontuações, foi criada uma data property, tendo como domain a classe Avaliação Risco Quedas e range do tipo xsd:integer. Cada parte foi criada de acordo com o seu contexto e as regras relacionadas às suas classes. A maioria dessas regras é composta por cálculos temporais, utilizando a data de criação da Avaliação de Risco de Queda e alguma outra data de referência, como a data de nascimento do paciente para classificar o paciente em faixas etárias.
Três abordagens foram usadas para realizar cálculos entre duas datas de acordo com as regras de pontuação: axiomas, SWRL Custom Temporal Built-Ins e SWRL Standard Mathematical Built-Ins com formato de data unix- time. A primeira abordagem empregada, a OWL possui funções internas para controlar datas em propriedades de dados de indivíduos. Essas funções podem ser usadas nos axiomas da classe para subtrair e somar dias, meses e anos, comparando se uma data é anterior ou posterior a uma data fixa na regra. No entanto, para calcular as pontuações da Avaliação de Risco de Queda, essas funções não são úteis. Foram necessárias funções que conseguissem extrair a diferença entre duas datas. A segunda abordagem foi a SWRL, que possui funções internas para controlar e manipular datas nas propriedades de dados. Além disso, há limitação de apenas subtrair dias, meses e anos, porém com mais funções para manipular durações e se uma data é anterior ou posterior a outra data. Existem extensões criadas a partir da SWRL que possibilitam estender as suas funções, chamadas de Built-Ins. Para isso, a própria SWRL possui um built-in nativo com funções matemáticas, controle de strings, manipulação de datas e até cálculos geométricos. Qualquer built-in criado pela comunidade é intitulado de built-in personalizado. Uma regra SWRL é processada quando todas as suas regras são reconhecidas como verdadeiras para o raciocinador que, por padrão, para a maioria dos aplicativos é o HermiT, capaz de processar regras padrão, mas incapaz de processar regras internas, nem mesmo as próprias da SWRL. Outro comumente utilizado é o Pellet, que também pode processar regras padrão e com built-ins, desde que sejam funções já atribuídas em seu código. A terceira abordagem foi importar o OWL-Time para a ontologia Avaliação Risco Quedas. OWL-Time é uma ontologia que possui conceitos e propriedades temporais. Para isso, ela usa datas no formato Unix-time. O timestamp unix é uma maneira de rastrear o tempo como um total de segundos em execução. Esta contagem começa no Unix Epoch em 1º de janeiro de 1970 no UTC. Assim, em vez de usar funções em SWRL para manipular datas, é possível usar a manipulação de inteiros de funções matemáticas.
A Figura 2 mostra a regra SWRL Em180dias para classificar uma instância temporal dentro de 180 dias da data da avaliação. Se todas as afirmações forem verdadeiras, a instância, sendo um TimeInstant, será classificada como dentro de 180 dias, representado como unix-time 130572.
Figura 2: SWRL para classificar uma instância temporal dentro de 180 dias da data da avaliação Ao utilizar datas no formato unix-time, foi encontrado um problema (bug) com o limite da propriedade xsd:integer, que corresponde ao inteiro da XSD, que tem um valor máximo de 2.147.483.647. Como solução, foi adotada a abordagem de dividir os valores das datas convertidas em unix-time por 100, incluindo as datas das regras SWRL.
Para calcular e classificar pacientes com mais de 80 anos, utilizando a data de nascimento. Considerando que os valores unix-time iniciaram em 1970, os pacientes com mais de 80 anos terão suas datas de nascimento em unix-time a partir da conversão de 1º de janeiro de 2050. Assim, é possível ter o valor de 80 anos em unix-time e esse valor excede o limite máximo dos inteiros. Portanto, ao dividir por 100, o valor é utilizável porque está dentro dos limites.
A interface de usuários permite que os usuários possam entrar com os dados do paciente. Ela é uma interface padrão para esse tipo de aplicação, mas que usa uma biblioteca para permitir a entrada de dados através da voz. Essa característica facilita a entrada de dados, já que a entrada padrão de dados textuais num tablet ou smartphone é ineficiente e o ambiente, enfermaria hospitalar, torna difícil o uso de notebooks ou desktops.
A avaliação da ferramenta está sendo feito usando-se um teste de usabilidade com enfermeiras que trabalham na enfermaria de um grande hospital de São Paulo e são responsáveis pela admissão de pacientes. As enfermeiras usaram a ferramenta para realizar as tarefas de entrada de dados obrigatórias durante uma admissão. Elas coletam dados do paciente, como peso, última refeição, remédios que toma, se teve alguma queda nos últimos meses, etc.
Depois de usar a ferramenta, cada enfermeira responde um questionário de avaliação onde é perguntado se a ferramenta traz ganhos de performance, se a funcionalidade atendeu as expectativas, quais as vantagens que ela vê no uso da ferramenta, etc. Até o momento, esse teste foi feito com duas enfermeiras, por isso consideramos os resultados até agora como preliminares, mas estamos procurando outras enfermeiras que tenham experiência na admissão de pacientes. Elas consideraram que houve um ganho na diminuição do tempo de preenchimento dos dados e de agilidade já que a ferramenta avisa sobre riscos de queda já no momento da admissão do paciente.
Durante o processo de desenvolvimento da solução, percebeu-se a necessidade de uma terminologia padronizada, como SNOMED-CT, para representar conceitos relacionados ao risco de queda. Assim como vários aspectos da classificação de risco de quedas são temporais, começando pela avaliação propriamente dita, evento de queda, jejum, entre outros. Por isso, foi incorporada a ontologia OWL-Time e foram armazenadas as datas/horas no formato Unix-Time para facilitar seu uso nas regras SWRL.
Como prova de conceito, desenvolveu-se uma ontologia usando o pacote Owlready2 e a API Flask conectada ao raciocinador para calcular os escores e classificar as avaliações de risco de queda. Os problemas de temporalidade foram resolvidos usando a ontologia OWL Time e os de cálculo com regras SWRL e embutidos matemáticos com datas no formato Unix Time.
Como trabalhos futuros, há expectativa de um aperfeiçoamento da ontologia, alimentando-a com dados reais de pacientes, bem como um refinamento no alinhamento entre o formato UnixTime e as regras SWRL. Vale ressaltar a importância de uma boa coleta de dados ea definição de métricas adequadas utilizando instrumentos como o JH-FRAT para a prevençãode risco de quedas. Otimizando desta forma o cuidado e a qualidade de vida do paciente. Além de adaptar a saída de resposta para interoperar com padrões conhecidos, por exemplo, criando um perfil FHIR para risco de queda. Permitindo assim a criação de um ambiente de ontologias interligadas de avaliações e cuidados de saúde, utilizando o motor de inferência para classificar pacientes e responder a possíveis riscos à saúde.