Como procuramos por sinais de erro médico

Em 2006, um aneurisma explodiu na cabeça do meu sogro e um acidente vascular cerebral o atingiu. Na noite daquele dia, ele estava brincando e tentando andar pela enfermaria do hospital. No segundo derrame, que ocorreu sob a supervisão de médicos, seu cérebro não aguentou: o sogro parou de conversar, andar e reconhecer parentes. Em outro hospital, ele foi colocado de pé, mas devido a um erro médico durante o tratamento inicial, ele ficou para sempre sem palavras e sua personalidade mudou além do reconhecimento.

O que aconteceu com ele é chamado de derrame hospitalar e este é um dos marcadores (ou não - gatilhos) de problemas sistêmicos em uma organização médica. Eles precisam ser analisados ​​para reduzir o número de erros médicos evitáveis ​​em hospitais e melhorar a qualidade do atendimento ao paciente.

Nos EUA, eles ficaram intrigados com essa questão no início dos anos 2000. O Instituto de Massachusetts para Melhoria da Assistência à Saúde (IHI) desenvolveu a Ferramenta de Gatilho Global da IHI para Medição de Eventos Adversos , que foi implementada pelas principais clínicas americanas e européias.

Em 2016, nós (o escritório russo da SAS) tentamos criar um sistema para analisar gatilhos médicos usando a metodologia IHI na Rússia. Vou te contar o que aconteceu.

Onde você começou

Primeiro, começamos a procurar médicos com idéias semelhantes que compartilham a ideia de analisar a qualidade dos cuidados médicos. Os chefes de vários hospitais de Moscou, os colegas do nosso escritório europeu e os representantes do hospital dinamarquês Lillebaelt foram convidados para o SAS Forum Russia 2016 , que criou um sistema de detecção de gatilhos usando a metodologia IHI em 2015, com base na plataforma analítica SAS.

A história dos dinamarqueses interessava ao médico chefe de um grande hospital multidisciplinar de Moscou e concordamos em realizar um experimento para analisar os registros médicos. Sob os termos da NDA, não podemos divulgar os detalhes do projeto, por isso continuarei chamando o hospital simplesmente de Clínica e seu chefe - o Médico Chefe.

De junho a julho de 2016, discutimos o conteúdo e o escopo do projeto com a gerência da clínica. Em agosto, redigimos os termos de referência e começamos a trabalhar em setembro. A espinha dorsal da equipe da SAS consistia em Alexander Zhukov ( al_undefined ) e Dmitry Kayatenko.

A técnica IHI contém 51 gatilhos. Juntamente com o gerenciamento da clínica, selecionamos o seguinte para o projeto:

• Leucócitos no sangue <3.000 x 10 ^ 6 / μl (exceto para pacientes em quimioterapia)
• Plaquetas sanguíneas <50.000 × 10 ^ 6 / μl (exceto para pacientes em quimioterapia)
• AVC nosocomial
• Infarto hospitalar
• Transferências não planejadas repetidas para a unidade de terapia intensiva (UTI) dentro de 24 horas
• Reanimação dentro de 24 horas após a cirurgia
• Medidas de ressuscitação nos departamentos de leito

Como costuma acontecer nas análises, a maior parte do tempo foi gasta pela preparação dos dados iniciais e pela alocação de informações significativas neles.

Como os registros foram recuperados

Os dados do sistema de informações médicas (MIS) da Clínica foram colocados em um banco de dados Oracle com uma estrutura complexa. Não foi possível encontrar as descrições dos esquemas; portanto, tive que restaurar a estrutura de dados e os relacionamentos entre entidades, comparando informações do banco de dados com informações da interface gráfica do MIS.

Para o projeto, precisávamos dos seguintes tipos de registros médicos:

• Dados do exame médico
• Tabela de diagnóstico
• Entradas do diário
• Protocolos de transação e conceitos pré-operatórios
• Informações sobre compromissos e desempenho
• Epicrisis em estágio e alta
• Epicrisis traduzidas
• Epicrisis póstuma

Esses dados (exceto a tabela de diagnósticos) estão em XML nos CLOBs. Não havia descrição da estrutura XML na Clínica, portanto, seu conteúdo teve que ser estabelecido empiricamente durante longas discussões.

Havia uma bagunça dentro dos documentos XML. Por exemplo, o nó "Condição geral" pode conter informações sobre as queixas dos pacientes, e o próprio nó "Reclamações" permanece vazio. Frequentemente, os médicos anotavam todos os dados sobre o paciente (reclamações, resultados de exames, recomendações para tratamento adicional e prescrição de medicamentos, etc.) em um campo, por exemplo, no Comentário.

O desenvolvimento de XML em tabelas simples foi realizado pelo SAS XML Mapper padrão. Os documentos mais complexos, com as informações necessárias em diferentes níveis de aninhamento, foram analisados ​​usando um analisador Python. Foi lançado a partir do SAS e foi integrado a um único processo executável do SAS Enterprise Guide:



Para não extrair os resultados dos testes de laboratório do texto da epicrisis (ainda é um prazer, dado o hábito de alguns médicos criar documentos), pegamos os dados deles no sistema de informações do laboratório (LIS). Eles também foram agrupados em XML, mas de uma forma simples - "análise", "indicador", "valor".

Como os dados foram pesquisados

Quando trouxemos os registros médicos de uma forma compreensível e adequada para processamento, verificou-se que apenas dois de sete gatilhos foram formalizados - o conteúdo de “glóbulos brancos” e “plaquetas”. Eles foram expressos em números que poderiam ser comparados com um valor limite.

Tivemos que abandonar a análise de um gatilho como "Transferências não planejadas repetidas para UTI dentro de 24 horas". Esse marcador depende de carimbos de data e hora e eles foram inseridos no IIA da clínica como Deus gostaria que fosse perfeito - eles poderiam faltar alguns dias ou até mesmo marcar uma data no futuro.

Ataques hospitalares, ataques cardíacos e medidas de ressuscitação não foram codificados de forma alguma e não foram registrados na tabela em relação ao ID do paciente. Eles deveriam ter sido procurados em epicrisis e entradas de diário. Portanto, os quatro gatilhos restantes eram informais, ou seja, exigiam análise do texto não estruturado.

Para fazer isso, usamos a ferramenta de processamento de linguagem natural - SAS Contextual Analysis . Esta é uma solução baseada na Web com uma interface visual que permite criar modelos de processamento de texto mesmo na ausência de habilidades de programação e conhecimento em linguística (no entanto, você ainda não pode prescindir do conhecimento da área de assunto e do idioma em que o texto está escrito).

Agora ficou na moda resolver esses problemas com a ajuda de redes neurais. Mas nós os deixamos conscientemente e aplicamos o mecanismo das regras lingüísticas, porque:

• Um bom resultado em redes neurais é possível apenas em uma amostra de alta qualidade, pré-marcada por médicos, médicos, com dezenas de milhares de registros, mas não obtivemos isso da palavra.
• a rede neural não fornece uma explicação clara de sua decisão (não pode ser interpretada) e os médicos não podem trabalhar com a caixa preta - eles devem entender exatamente quais sintomas, indicadores ou ações indicam eventos adversos

Como treinar o sistema

Embora tenhamos lidado com todos os gatilhos da lista, os principais esforços foram focados na detecção de derrames hospitalares e ataques cardíacos (chamaremos as infecções nosocomiais por questões de brevidade). Esses são alguns dos gatilhos mais perigosos que, além de prejudicar a saúde dos pacientes, são terríveis porque não são anunciados pela equipe médica. E se a gerência não souber sobre o problema, ele não poderá lidar com isso.

Tudo não foi fácil com o NSI. Não havia um padrão ou regulamento que obrigasse a documentar os fatos de derrames ou ataques cardíacos de forma uniforme: alguns médicos descreveram o derrame como um "acidente vascular cerebral agudo", outros como (ah, sim!) "Derrame" e outros como "ONMK" " Às vezes, infecções nosocomiais eram visíveis apenas com o tratamento prescrito.

Basicamente, poderíamos:

1. Entreviste todos os médicos sobre como eles descrevem derrames e ataques cardíacos. No entanto, havia o risco de perder algo - ninguém lembra da lista de registros feitos uma vez e do diretório de abreviações. E havia poucas pessoas que desejavam falar sobre esse assunto.
2. Juntamente com os médicos, passe por toda a epicrisis e analise se eles têm sinais de infecções nosocomiais ou não. Mas nem nós nem eles tivemos tanto tempo.

Agimos de maneira diferente: fizemos o upload de uma coleção de textos em Análise Contextual e construímos modelos temáticos que destacavam as principais ideias para cada entrada. Sem entrar no texto do documento (por exemplo, uma epicrisis), era possível selecionar apenas registros com o tema "acidente vascular cerebral" ou "NMC" e examiná-los separadamente para saber como o VBI é descrito no texto: quais palavras são usadas, a que distância umas das outras Além disso, os próprios modelos sugeriram possíveis formulações para descrever idéias-chave.

Após a marcação temática dos documentos, conversamos com os médicos, esclarecemos e desenvolvemos regras lingüísticas para identificar eventos que indicam gatilhos. As regras levaram em conta as formas gramaticais das palavras, a distância entre elas, a ordem de sua sequência, posição (em uma frase, parágrafo, início / fim do texto), etc.

Estávamos procurando medidas de ressuscitação:



E assim - traços:



Ao analisar o texto, você sempre precisa avaliar a distância entre as palavras-chave e a ordem delas, para não capturar muito. Aqui está um exemplo quando todas as palavras necessárias ("aguda", "violação", "cérebro", "circulação sanguínea") estão na frase, mas o derrame nosocomial não é:



Era muito importante separar a descrição do fato de um acidente vascular cerebral nosocomial da descrição das consequências de um acidente vascular cerebral anterior, no qual as mesmas palavras-chave foram usadas:



A regra excluída "As consequências de um acidente vascular cerebral" (acima em Remove_item):



Juntamente com os médicos, desenvolvemos cerca de 30 regras lingüísticas que determinavam se havia sinais de gatilhos na epicrisis. Eles foram baixados da Análise Contextual na forma de código de pontuação, que foi conectado ao processo executável para avaliar registros no SAS Enterprise Guide.

No entanto, para derrames hospitalares e ataques cardíacos, o processo de tomada de decisão sobre a presença de um gatilho não termina aí. Deveríamos ter removido da lista de candidatos ao gatilho os casos que poderiam ter sido previstos na admissão do paciente. Para fazer isso, comparamos os resultados do trabalho de regras com uma tabela de diagnósticos.

Deixe-me lembrá-lo de que um gatilho é um evento (agravando a condição do paciente), inesperado em termos de diagnóstico na admissão. Este é um sinal de um erro médico ou de um problema hospitalar que exige medidas sistemáticas para excluir complicações no futuro, e não apenas qualquer deterioração na saúde do paciente.

Digamos que a Análise Contextual tenha atribuído o rótulo "infarto nosocomial" a algum registro. Verificamos o diagnóstico: se o paciente foi internado com doença coronariana, o risco de infarto do miocárdio já era alto. Este evento, embora não seja favorável, mas, infelizmente, esperado. O atributo de disparo do registro não está atribuído.

Se o paciente foi admitido com apendicite e teve um acidente vascular cerebral durante o tratamento, isso pode ser um erro médico. Por exemplo, eles não seguiram a pressão ou provocaram um salto com algumas drogas ou ações. Os registros atribuem o atributo "gatilho".

O resultado é um processo de negócios:



Era conveniente para os médicos - eles poderiam complementar independentemente as regras lingüísticas para a análise da epicrisis, que foram então carregadas no código de pontuação e captadas pelo sistema analítico.

Como os dados foram visualizados

No último estágio, configuramos o relatório no SAS Visual Analytics - este é o nosso produto baseado na Web para tarefas de visualização e BI. Foi atualizado a cada 5 minutos e mostrou as estatísticas da ocorrência de gatilhos no contexto de departamentos, médicos e pacientes. O médico responsável (por exemplo, o chefe do departamento de cardiologia) entrou no relatório e examinou quais gatilhos foram detectados na última hora, dia, semana. Pode "falhar" no departamento, ver a dinâmica do gatilho para o período, etc .:



Para não carregar o artigo com capturas de tela (ainda mais "borradas"), registramos uma pequena demonstração sobre dados despersonalizados:


Também queríamos configurar a notificação automática de gatilhos - esse é um bom tom para sistemas analíticos que monitoram indicadores críticos. Além disso, a funcionalidade da lista de discussão é incorporada ao SAS Visual Analytics. Mas a Clínica não queria dar acesso ao servidor de correio, assim como ela se recusou a organizar o envio de SMS por meio do emparelhamento com serviços externos.

Como tudo terminou

A gerência do hospital conduziu um experimento comparando os resultados da detecção manual de gatilhos de eventos adversos por uma equipe de médicos especialistas e uma análise automática realizada pelo sistema SAS. O resultado não foi favorável às pessoas: o sistema SAS detectou mais do que o conselho médico. Para alguns gatilhos - várias vezes mais:



Mas o aumento da precisão não é a principal coisa que o sistema de detecção de gatilhos deu. Mais importante, ela permitiu:

1. Garantir o monitoramento contínuo de todos os registros médicos. Não por acaso selecionado ou os casos mais flagrantes, mas aos poucos. Não apenas uma vez por trimestre, mas em um modo próximo ao tempo real.
2. Libere tempo para o pessoal altamente qualificado se envolver em atividades principais. Somente dentro da estrutura do experimento a equipe médica poderia ficar intrigada com uma auditoria manual em larga escala. No modo normal, não há tempo para fazer isso - se os médicos estiverem ocupados com anotações, não haverá ninguém para tratar as pessoas.

Importante para o sucesso do projeto foi o apoio total da administração - o médico chefe, seus representantes e chefes de departamento. O chefe da clínica foi educado nos EUA; portanto, a idéia de gerenciamento baseada em gerenciamento de qualidade e análise automatizada de dados acabou por ser próxima e clara para ele

Infelizmente, pouco antes da implementação em larga escala do sistema analítico, o Médico Chefe renunciou. Seu sucessor era francamente conservador e não gostava de fazer roupa suja em público. A clínica anotou os resultados do promissor projeto "para a mesa" e voltou aos métodos de trabalho testados por anos de prática.

Embora não seja agradável fazer um produto não reclamado, a experiência do experimento na Clínica foi muito útil para nós no próximo projeto de auditoria de registros médicos no sistema de seguro médico obrigatório. Mas mais sobre isso em outra hora.