Tópico 4.7 — Apoio à decisão clínica e informática clínica

O apoio à decisão clínica é conhecimento clínico transformado em software que dispara no ponto de cuidado; por isso acertá-lo — o estímulo certo à pessoa certa no momento certo, e nenhum outro — é uma disciplina de segurança clínica, de fluxo de trabalho e de confiança pública, e não uma reflexão tardia de configuração.

Por que isso importa na saúde e nos cuidados#

Toda prescrição, encaminhamento, pedido de exame e diagnóstico num serviço de saúde moderno passa hoje por um software que pode ajudar ou atrapalhar a decisão. Um alerta bem projetado impede uma interação medicamentosa letal antes que chegue ao paciente; um mal projetado dispara com tanta frequência que os clínicos aprendem a dispensá-lo sem ler e, no dia em que importa, também o dispensam. O mesmo mecanismo que previne o dano pode fabricá-lo. É por isso que o apoio à decisão não é uma funcionalidade que se liga, mas um corpo de conhecimento clínico que se governa, com a mesma seriedade com que se trata um medicamento ou um dispositivo.

O que está em jogo é distintivo de três maneiras. Primeiro, o apoio à decisão opera em escala e em velocidade: uma única mudança de regra se propaga instantaneamente a milhares de clínicos e milhões de atendimentos; assim, um erro sutil é um erro sistêmico. Segundo, é crítico para a segurança por construção — um alerta que suprime um aviso genuíno, ou uma calculadora que arredonda mal uma dose pediátrica, é um perigo que o software introduziu (ver Tópico 1.6 — Segurança clínica e gestão de riscos). Terceiro, molda o comportamento clínico quer você pretenda ou não: o que o sistema facilita vira o padrão, e o que ele interrompe passa a ser ressentido. O apoio à decisão é, portanto, um exercício de influência, e a influência na saúde nunca é neutra.

Por trás do software há uma profissão. A informática clínica é a disciplina que liga a prática clínica, a informação e a tecnologia, e é a razão pela qual o apoio à decisão pode ser escrito por pessoas que entendem tanto a medicina quanto a máquina. Sem essa profissão — sem diretores clínicos de informação, responsáveis pela segurança clínica e clínicos treinados em informática na sala —, o apoio à decisão deriva rumo ao que um fornecedor entregou por padrão, ajustado por ninguém, de propriedade de ninguém e em que todos confiam até que falhe. Tratar o apoio à decisão como uma configuração técnica, e não como um ativo clínico governado, é como as organizações acabam com milhares de regras de que ninguém se lembra de ter escrito e que ninguém ousa desligar.

Conceitos centrais#

Um sistema de apoio à decisão clínica (CDSS, ou simplesmente CDS) é uma tecnologia da informação em saúde que dá a clínicos, equipe ou pacientes conhecimento e informações específicas da pessoa, filtrados de forma inteligente e apresentados em momentos apropriados, para melhorar uma decisão. A taxonomia clássica distingue várias formas. Alertas e lembretes interrompem para avisar ou instigar — um aviso de interação entre medicamentos, um lembrete de vacinação atrasada. Os conjuntos de pedidos agrupam os exames, medicamentos e instruções apropriados a uma situação, para que as coisas certas sejam pedidas juntas. As vias de cuidado codificam uma via clínica — uma sequência padronizada e baseada em evidências de cuidados — no fluxo de trabalho. Os modelos de documentação estruturam o que é registrado para que nada essencial seja perdido. O apoio diagnóstico sugere ou classifica possíveis diagnósticos. E as calculadoras implementam um algoritmo médico — um cálculo de dose, uma pontuação de risco, uma TFGe —, para que a aritmética seja feita de forma consistente.

A ideia organizadora da qualidade são os "cinco certos" do apoio à decisão: entregar a informação certa, à pessoa certa, no formato certo, pelo canal certo, no momento certo do fluxo de trabalho. Uma regra pode estar clinicamente correta e ainda assim falhar em todos eles — informação exata dada ao papel errado, como uma parada obrigatória quando uma exibição passiva bastaria, enterrada numa tela que ninguém lê, minutos depois de a decisão já ter sido tomada. A maioria das falhas de apoio à decisão não é falha de conhecimento médico; é falha de um ou mais dos cinco certos.

O modo de falha dominante tem nome próprio. A fadiga de alarmes (também chamada de fadiga de alertas) é a dessensibilização que se instala quando os clínicos enfrentam tantos avisos que deixam de atendê-los, anulando o importante junto com o trivial. Como a maioria dos alertas de um sistema típico é anulada, a taxa de anulação é um sinal vital da saúde do apoio à decisão: uma taxa alta significa que o sistema está treinando seus usuários a ignorá-lo. A cura não é mais alertas, mas menos alertas, mais afiados e mais bem direcionados.

Dois conceitos governam o quão bem o apoio à decisão pousa. O apoio à decisão vive dentro do prontuário eletrônico de saúde (EHR, chamado de prontuário eletrônico do paciente ou EPR no NHS) e muitas vezes dentro da entrada computadorizada de pedidos médicos (CPOE); assim, tem sucesso ou fracassa como parte de um sistema sociotécnico mais amplo — a teia interativa de pessoas, tarefas, tecnologia e organização. Uma regra que ignora o fluxo de trabalho real, por mais sólida que seja a sua lógica, vira atrito a ser contornado. E o próprio conteúdo é um ativo de conhecimento: as regras codificam a medicina baseada em evidências e uma diretriz médica, que mudam com o tempo; portanto, o apoio à decisão precisa ser redigido, revisto, versionado e aposentado como qualquer outro corpo de conhecimento clínico (ver Tópico 10.3 — Gestão do conhecimento e documentação).

A informática em saúde — e sua subdisciplina clínica, a informática clínica — é o campo que estuda e aplica a informação e a tecnologia aos cuidados de saúde. No Reino Unido, ela se profissionalizou por meio da Faculty of Clinical Informatics e de papéis como o Diretor Clínico de Informação (CCIO) e o Diretor de Enfermagem de Informação (CNIO). Historicamente, boa parte da lógica das regras era expressa na sintaxe Arden, um padrão para representar conhecimento médico compartilhável como Módulos de Lógica Médica; hoje, padrões como o HL7 CDS Hooks e o Clinical Reasoning baseado em FHIR visam tornar o apoio à decisão compartilhável entre sistemas (ver Tópico 4.3 — Interoperabilidade e padrões de dados). Por fim, note a fronteira deste tópico: ele responde pelo apoio baseado em regras e em conhecimento e pela profissão da informática. As abordagens estatísticas e de aprendizado de máquina — incluindo o diagnóstico assistido por computador e o software como dispositivo médico — são governadas como inteligência artificial (ver Tópico 8.4 — Governança de IA e de tecnologias emergentes).

Boas práticas#

  1. Projete para os cinco certos e trate o alerta como último recurso. Antes de construir qualquer regra, pergunte a qual dos cinco certos ela serve e se uma interrupção é mesmo o instrumento certo. Prefira tornar o caminho seguro o caminho fácil — uma dose padrão sensata, um conjunto de pedidos preenchido, um modelo que estrutura uma boa documentação — a um aviso que pune o inseguro depois do fato. Um alerta interruptivo é a forma mais cara de apoio à decisão, porque gasta o recurso mais escasso do prédio: a atenção clínica. Reservem-no para perigos que sejam graves, acionáveis e específicos o bastante para justificar parar um clínico ocupado.

  2. Governe o conteúdo de apoio à decisão como um ativo de conhecimento clínico com ciclo de vida. Toda regra, conjunto de pedidos e modelo precisa de um responsável clínico nomeado, uma base de evidências, uma data de revisão, um histórico de versões e uma via definida de aposentadoria. Estabeleçam um grupo de governança de conteúdo clínico — clínicos, farmacêuticos, informáticos e um responsável pela segurança clínica — que autorize o que entra em produção, revise-o em cronograma e aposente o que a evidência ultrapassou. Sem isso, o conteúdo se acumula: as regras se multiplicam, se contradizem e sobrevivem às orientações em que foram baseadas, e ninguém tem confiança suficiente para desligar qualquer uma.

  3. Meça as taxas de anulação e cace o ruído. O sinal isolado mais útil da saúde do apoio à decisão é com que frequência os clínicos anulam cada alerta, desdobrado por regra, especialidade e papel. Uma regra anulada quase toda vez que dispara não protege ninguém — está treinando os usuários a ignorar todo o sistema, inclusive os alertas que importam. Revejam regularmente os piores infratores e ajam: aposentem-nos, estreitem seus critérios de disparo, rebaixem-nos de interruptivos para passivos ou corrijam o problema de dados subjacente que os faz disparar espuriamente. Reduzir o ruído é uma atividade de segurança tanto quanto acrescentar uma nova regra.

  4. Escalone seus alertas por gravidade e torne a interrupção proporcional. Nem todo aviso merece parar o mundo. Projetem uma hierarquia deliberada — uma parada obrigatória genuína para o perigo raro e catastrófico; um aviso interruptivo, mas anulável, para riscos graves; e informação passiva e não bloqueante para o meramente útil. Ajustem o atrito ao que está em jogo clinicamente e exijam um motivo para anular apenas os alertas graves o bastante para justificar a tecla extra. Quando tudo é urgente, nada é, e o aviso verdadeiramente perigoso se afoga no trivial.

  5. Incorpore o apoio à decisão ao fluxo de trabalho real, e não por cima dele. Uma regra clinicamente perfeita, mas que chega ao passo errado, na tela errada, para o papel errado, será contornada ou ignorada (ver Tópico 8.3 — Ciência comportamental e adoção). Projetem com os clínicos que a usarão — observem a tarefa real, mapeiem onde a decisão é de fato tomada e coloquem o apoio ali. Testem-no num ambiente realista antes da entrada em produção e observem o que as pessoas fazem, porque a distância entre o fluxo de trabalho projetado e o vivido é onde o apoio à decisão falha em silêncio.

  6. Mantenha um humano firmemente no circuito e preserve o julgamento clínico. O apoio à decisão aconselha; o clínico decide e continua responsável. Projetem de modo que anular seja possível, rápido e, onde importa, registrado com um motivo — tanto para respeitar o julgamento profissional quanto para gerar os dados que melhoram a regra. Cuidado com o viés de automação, a tendência de confiar demais na sugestão da máquina: um estímulo diagnóstico que ancora um clínico na resposta errada pode ser tão danoso quanto nenhum estímulo. O objetivo é ampliar a expertise, jamais desqualificar nem assumir em silêncio uma responsabilidade que o sistema nunca foi construído para carregar.

  7. Conduza o apoio à decisão sob a gestão da segurança clínica e a profissão da informática. Tratem toda nova regra e toda mudança como um caso de segurança clínica sob as normas do NHS DCB0129 (fabricante) e DCB0160 (implantador), com um responsável pela segurança clínica aprovando a análise de perigos (ver Tópico 1.6 — Segurança clínica e gestão de riscos). Deem ao trabalho uma propriedade profissional: um CCIO ou CNIO responsável pelo conteúdo clínico, clínicos treinados em informática redigindo-o e uma via para que a equipe da linha de frente relate um alerta que esteja errado, ausente ou danoso. O apoio à decisão sem um responsável clínico nomeado é um sistema de segurança órfão à espera de falhar.

  8. Avalie a eficácia frente aos desfechos e seja honesto quando não funciona. O propósito de uma regra é mudar uma decisão para melhor; meçam, portanto, se ela o faz — uma prescrição que ficou mais segura, um exame que deixou de ser pedido em excesso, uma via que os pacientes de fato completaram —, e não meramente que o alerta disparou (ver Tópico 8.6 — Pesquisa e avaliação em mundo real). Atenção às consequências não intencionais: alertas que deslocam trabalho para outro papel, gambiarras que criam novos perigos ou estímulos "corretos" que acrescentam tempo sem mudar desfechos. Onde a evidência diz que uma regra acrescenta atrito sem benefício, aposentem-na. A contenção — desligar coisas — é uma forma madura de apoio à decisão, e não um recuo dela.

Perguntas para discutir com a sua equipe#

  1. Quais dos nossos alertas de fato protegem pacientes, e quais estão apenas treinando nossos clínicos a clicar em "anular"? Isto importa porque um sistema de apoio à decisão é tão confiável quanto os seus piores alertas: um punhado de avisos ruidosos e quase inúteis ensina os clínicos a dispensar tudo por reflexo, de modo que, no dia em que um perigo genuíno dispara, ele é anulado com o resto. Puxem as taxas reais de anulação por regra e papel e sejam honestos sobre o que uma taxa de anulação de 95% está dizendo — não que os clínicos são descuidados, mas que a regra está errada para o fluxo de trabalho. Debatam a concessão mais difícil: cada alerta que vocês aposentam remove uma rede de segurança teórica, e alguém perguntará "e se o único caso que perdermos for o que desligamos?". Uma boa resposta, honesta, resiste a esse enquadramento, reconhecendo que um alerta ignorado não protege ninguém, e se compromete a ajustar ativamente o parque para baixo — aposentando, estreitando ou rebaixando as regras mais ruidosas — em vez de apenas acrescentar novas. Também nomeia quem tem poder para desligar uma regra, porque, se a resposta for "ninguém ousa", o sistema só ficará mais ruidoso.

  2. Quem é dono do nosso conteúdo de apoio à decisão como conhecimento clínico — e saberíamos se uma regra se baseasse numa orientação que mudou há dois anos? As regras de apoio à decisão codificam evidências e diretrizes clínicas que evoluem, e, no entanto, em muitas organizações o conteúdo foi configurado uma vez na entrada em produção por um fornecedor e nunca foi revisado sistematicamente desde então. Discutam se toda regra, conjunto de pedidos e modelo tem um responsável clínico nomeado, uma base de evidências, uma data de revisão e um histórico de versões, ou se grandes partes do parque estão, na prática, sem dono e sem auditoria. Tragam à tona a tensão entre o esforço de uma governança de conteúdo adequada e o ritmo em que as orientações mudam: ninguém tem tempo de revisar milhares de regras, de modo que o risco é que a revisão aconteça para nenhuma. Considerem a falha concreta — um limite de dose ou uma regra de interação que reflete uma orientação superada, silenciosamente errada em todo atendimento que toca. Uma boa resposta estabelece um grupo permanente de governança de conteúdo clínico com autoridade real, um cronograma de revisão baseado em risco que priorize o conteúdo de maior dano e uma via clara de aposentadoria e admite com franqueza onde hoje a resposta honesta é "não sabemos quando isto foi verificado pela última vez".

  3. Como construímos e avaliamos o apoio à decisão para que se encaixe no modo como os clínicos de fato trabalham — e como saberíamos se ele piorou as coisas? Uma regra pode ser medicamente impecável e ainda assim falhar porque chega no momento errado, interrompe o papel errado ou empurra trabalho para alguém a jusante que nunca o pediu. Discutam se o seu apoio à decisão é projetado com clínicos da linha de frente observando o fluxo de trabalho real ou configurado por pessoas lendo uma especificação que nunca viram a tarefa ser realizada. Debatam o que significa "sucesso": contagens de disparo e taxas de cliques são fáceis de coletar, mas dizem quase nada, enquanto os desfechos mudados e o dano evitado são o que importa e são muito mais difíceis de medir (ver Tópico 8.6 — Pesquisa e avaliação em mundo real). Tragam à tona as consequências não intencionais a que vocês podem estar cegos — gambiarras que criam novos perigos, viés de automação ancorando um clínico num estímulo errado ou tempo acrescentado sem benefício. Uma boa resposta trata toda regra significativa como uma mudança a avaliar, e não um interruptor a acionar, combina sinais quantitativos com a observação de usuários reais e está disposta a concluir que uma regra bem-intencionada deve ser removida.

  4. Quando mudamos uma regra de apoio à decisão, tratamos isso como uma mudança de segurança clínica com análise de perigos — ou como uma edição rotineira de configuração? Uma única mudança de regra se propaga instantaneamente a milhares de clínicos e milhões de atendimentos; assim, a diferença entre esses dois enquadramentos é a diferença entre um ativo clínico governado e um não governado. Discutam com honestidade se toda mudança relevante hoje passa por um caso de segurança clínica sob a DCB0129 e a DCB0160, com um responsável pela segurança clínica aprovando a análise de perigos, ou se as mudanças são feitas numa tela de configuração por pessoas que nunca as veem como críticas para a segurança (ver Tópico 1.6 — Segurança clínica e gestão de riscos). Tragam à tona a tensão: uma avaliação de segurança adequada acrescenta atrito e retarda a entrega e, sob pressão, é a primeira coisa a ser pulada em favor da correção "óbvia". No entanto, o caso-limite perigoso — a interação que o ajuste silenciosamente desmascara, o limite de dose que a mudança "pequena" remove em silêncio — é exatamente o que a análise de perigos existe para pegar. Uma boa resposta nomeia quem responde quando uma regra causa dano, insiste que até edições de aparência menor carreguem uma avaliação de segurança proporcional e consegue mostrar a trilha de auditoria que o prova, em vez de descobrir após um incidente que ninguém registrou por que a mudança foi feita.

  5. O nosso apoio à decisão funciona igualmente bem para todos os grupos de pacientes — ou importamos um viés que não conseguimos ver? A lógica do apoio à decisão codifica limiares, pontuações de risco e suposições de via que muitas vezes foram derivados de populações específicas, e uma regra que é sólida "em média" pode estar sistematicamente errada para grupos sub-representados nas evidências em que repousa. Discutam onde as suas regras embutem variáveis — cálculos ajustados por etnia, pontos de corte por idade ou sexo, suposições sobre quem se apresenta de que modo — e se alguém verificou como elas se comportam entre as pessoas que vocês de fato atendem. Tragam à tona a tensão mais difícil: remover um ajuste clinicamente válido pode prejudicar tanto quanto manter um enviesado; assim, não se trata de arrancar toda variável demográfica, mas de saber quais são baseadas em evidências e quais são hábito herdado. Considerem o dever de equidade que um órgão nacional ou comissionador esperará que vocês cumpram e a questão da transparência de se a lógica e sua proveniência resistiriam ao escrutínio se publicadas. Uma boa resposta se compromete a auditar as regras de alto impacto quanto a efeito diferencial, trata a proveniência e a explicabilidade como requisitos de primeira ordem e é honesta de que, para grande parte do parque, a resposta atual é "nunca olhamos".

  6. Onde traçamos a linha entre apoiar o julgamento de um clínico e substituí-lo em silêncio — e estamos criando viés de automação? O apoio à decisão deve ampliar a expertise, mas um sistema que faz da sugestão da máquina o caminho de menor resistência pode ancorar os clínicos numa resposta errada e, com o tempo, corroer o próprio julgamento que presume que eles ainda têm. Discutam se o seu projeto mantém a anulação genuinamente fácil e legítima, ou se o atrito, os padrões e o enquadramento empurram os clínicos a aceitar estímulos que deixaram de escrutinar. Debatam com franqueza o risco de desqualificação: se os residentes aprendem medicina por um sistema que sempre sugere o passo seguinte, o que acontece no dia em que o sistema está errado ou indisponível? Pesem isso frente ao perigo igual da fadiga de alertas no outro extremo — o objetivo é a confiança calibrada, e não a conformidade total nem a resistência total. Uma boa resposta preserva, por projeto, uma responsabilização humana significativa, observa os sinais reveladores de excesso de confiança, como a aceitação quase universal de um estímulo diagnóstico, e é clara de que o sistema aconselha enquanto o clínico decide e continua responsável.

Na prática: um exemplo de saúde e cuidados#

O Kingsmere NHS Foundation Trust, parte do Riverdale and Vale Integrated Care System, entrou em produção com um novo prontuário eletrônico do paciente há dois anos. O conteúdo clínico veio em grande parte da biblioteca padrão do fornecedor, levemente localizada durante uma implantação apressada. Neste ano, os clínicos reclamam em voz alta: o sistema é "só pop-ups", os médicos juniores descrevem clicar em avisos sem ler e um farmacêutico levantou uma preocupação de segurança depois que um alerta grave de interação foi anulado em um conjunto de casos — porque se parecia exatamente com as dezenas de alertas triviais que disparam a cada plantão.

O CCIO do hospital encomenda uma revisão do apoio à decisão. A equipe de informática puxa os dados de anulação e constata que um pequeno número de regras responde pela esmagadora maioria dos alertas e que várias disparam em quase toda prescrição, com taxa de anulação acima de 90%. Uma regra de terapia duplicada dispara em combinações legítimas; um alerta de dosagem renal dispara sobre resultados de creatinina desatualizados por causa de um problema de tempo dos dados, e não de um perigo real. Enquanto isso, o alerta de interação genuinamente perigoso está enterrado, visualmente idêntico ao ruído, sem exigência de registrar um motivo para anulá-lo.

Um grupo de governança de conteúdo clínico é montado, presidido pelo CCIO, com um responsável pela segurança clínica, farmacêuticos, enfermeiros seniores e um analista de dados. Agem com base na evidência, e não acrescentando mais regras. A regra de dosagem renal é corrigida na origem, resolvendo o problema de tempo dos dados. A regra de terapia duplicada é estreitada para que deixe de disparar em pares legítimos. Um esquema escalonado de gravidade é introduzido: a interação grave vira um alerta distinto, mais difícil de dispensar, que exige um motivo documentado, enquanto uma longa cauda de avisos de baixo valor é rebaixada a informação passiva ou aposentada de vez. Toda mudança passa por uma avaliação de segurança clínica DCB0160.

Seis meses depois, o volume total de alertas caiu acentuadamente, enquanto a taxa de anulação dos alertas de alta gravidade restantes diminuiu, porque os clínicos agora confiam que um aviso que os detém significa algo. O grupo de governança fixou datas de revisão para cada regra sobrevivente, atribuiu a cada uma um responsável clínico e começou a avaliar se os conjuntos de pedidos de fato mudaram a prescrição para melhor. O trabalho não acrescentou nenhuma capacidade dramática nova — em sua maior parte, desligou coisas e ajustou coisas para baixo —, mas converteu uma pilha de pop-ups sem dono e desacreditada num sistema de segurança clínica governado e confiável.

Perspectivas setoriais#

Startup#

Uma startup de saúde digital que incorpora apoio à decisão — uma ferramenta de triagem, uma calculadora de risco, um módulo de apoio à prescrição — costuma estar do lado do fabricante da linha e deve tratar suas regras como conhecimento clínico regulado desde o início. Mesmo uma calculadora "simples" que recomenda uma ação pode ser software como dispositivo médico, o que a puxa para a regulação da MHRA e exige um caso de segurança clínica sob a DCB0129 (ver Tópico 1.5 — Panorama de regulação e conformidade). A tentação é entregar depressa uma lógica engenhosa; a disciplina é documentar a base de evidências, versionar o conteúdo e projetar para a anulação graciosa e a supervisão humana antes que o primeiro clínico dependa dela. A credibilidade de uma startup junto a um comprador do NHS repousa tanto em como ela governa e atualiza seu conteúdo clínico quanto na engenhosidade do algoritmo.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou uma clínica de unidade única — consome sobretudo o apoio à decisão embutido no sistema clínico de um fornecedor, e não o redige, mas carrega o mesmo dever de usá-lo com segurança e manter o julgamento clínico no circuito. Com pouca ou nenhuma capacidade de informática dedicada, as prioridades práticas são estreitas, mas reais: saiba quais alertas o seu sistema está disparando e desligue ou ajuste os locais que viraram ruído, mantenha atualizado o conteúdo de medicamentos e orientações em vez de congelado na instalação e garanta que alguém — mesmo um líder clínico de meio período — responda pela segurança de qualquer personalização local. Resista à tentação de desativar avisos em bloco só porque são irritantes, já que isso troca um incômodo por um perigo. Onde as regras padrão de um fornecedor estiverem claramente erradas para os seus pacientes, levante a questão com o fornecedor e registre a preocupação, porque você depende da governança dele no lugar de uma interna. As questões de equidade e de proveniência ainda se aplicam, mesmo que respondê-las signifique fazer melhores perguntas ao seu fornecedor, e não auditar código você mesmo.

Grande organização#

Um grande hospital do NHS ou grupo hospitalar normalmente herda milhares de regras da biblioteca padrão de um fornecedor de EHR, e seu desafio central é a governança em escala, e não redigir do zero. O objetivo realista é uma função permanente de governança de conteúdo clínico, análises confiáveis de anulação, um esquema escalonado de alertas e a disciplina de aposentar e ajustar em vez de apenas acumular — e não uma regra perfeitamente sob medida para cada situação. Incorporem as mudanças de apoio à decisão ao controle clínico de mudanças e ao sistema de gestão de segurança clínica, com um CCIO ou CNIO responsável e clínicos treinados em informática fazendo o trabalho (ver Tópico 4.6 — Prontuários eletrônicos do paciente e sistemas clínicos). Nessa escala, os maiores ganhos de segurança vêm de cortar ruído e assumir o conteúdo, e não de acrescentar cada vez mais alertas.

Governo#

Um órgão nacional — NHS England, MHRA, NICE — molda o ambiente de apoio à decisão em que todo prestador trabalha. Pode curar e assegurar a qualidade de conhecimento compartilhável (orientações do NICE, dados de medicamentos do BNF e do dm+d), definir as normas de segurança clínica DCB0129 e DCB0160 e zelar por padrões de interoperabilidade para que uma regra redigida uma vez possa ser confiável e reutilizada, em vez de reconstruída em cada hospital (ver Tópico 9.1 — Trabalho com governos locais e nacionais). Sua alavancagem é tornar o apoio à decisão bem governado e ligado a evidências o padrão do mercado por meio de normas, marcos de compra e infraestrutura profissional como a Faculty of Clinical Informatics. O governo também carrega os deveres de equidade e de transparência: garantir que a lógica do apoio à decisão não codifique viés contra determinados grupos e que sua proveniência seja auditável e pública.

Modos de falha comuns#

  • Sobrecarga de alertas. Disparar um aviso para cada risco imaginável dessensibiliza os clínicos até que anulem tudo, inclusive os alertas que importam. Escalonem por gravidade, meçam as taxas de anulação e cortem o ruído sem dó.
  • Conteúdo sem dono e sem revisão. Regras configuradas uma vez na entrada em produção e nunca revisitadas derivam das orientações atuais e codificam em silêncio evidências superadas. Deem a cada regra um responsável nomeado, uma base de evidências e uma data de revisão.
  • Padrões do fornecedor sem ajuste. Entregar a biblioteca de regras de fábrica do fornecedor sem localizá-la ao seu fluxo de trabalho e formulário importa o ruído e as suposições de outra pessoa. Revejam e ajustem antes da entrada em produção, e não depois das reclamações.
  • Lógica sem fluxo de trabalho. Uma regra clinicamente correta posta no passo, na tela ou no papel errado vira atrito que os clínicos contornam. Projetem e testem com usuários da linha de frente na tarefa real.
  • Contagens de disparo confundidas com eficácia. "O alerta disparou 10.000 vezes" nada diz sobre se alguma decisão melhorou. Avaliem frente a desfechos mudados e dano evitado e fiquem atentos às consequências não intencionais.
  • Sem caso de segurança. Tratar uma mudança de regra como edição rotineira de configuração, e não como mudança de segurança clínica, pula a análise de perigos que pega o caso-limite perigoso. Encaminhem toda mudança pela DCB0160.
  • Viés de automação e desqualificação. Confiar demais no estímulo da máquina pode ancorar um clínico na resposta errada ou corroer o julgamento que o sistema presume. Mantenham supervisão humana significativa e projetem de modo que anular seja fácil e legítimo.

Modelo de maturidade#

Dimensão Iniciar Desenvolver Padronizar Gerir Orquestrar
Governança de conteúdo Padrões do fornecedor, sem responsável nem revisão Algumas regras revistas ad hoc após reclamações Responsáveis clínicos nomeados, base de evidências, revisão agendada, via de aposentadoria Conclusão das revisões e atualidade do conteúdo acompanhadas frente a metas, com governança assegurada Curadoria contínua, baseada em risco, ligada a fontes nacionais de conhecimento
Projeto de alertas Tudo interruptivo; sem níveis de gravidade Alguns alertas de alto risco distinguidos informalmente Hierarquia deliberada de gravidade; motivos registrados para anulações graves Carga de alertas e limiares de anulação monitorados frente a limites acordados e geridos ativamente Atrito proporcional ajustado por evidências; caminho seguro tornado o padrão
Medição Sem visibilidade de dados de anulação ou disparo Contagens de disparo disponíveis, raramente usadas Taxas de anulação monitoradas por regra e papel, com ação tomada KPIs de anulação e eficácia reportados à governança, com metas e ação corretiva Eficácia avaliada frente a desfechos clínicos e consequências não intencionais
Fluxo de trabalho e adequação sociotécnica Regras configuradas a partir de especificação, não da prática observada Alguma contribuição de clínicos no projeto Codesenhado com usuários da linha de frente, testado antes da entrada em produção Adequação pós-implantação medida e gerida por retorno estruturado dos usuários e acompanhamento de gambiarras Refinado continuamente a partir do uso observado e de ciclos de retroalimentação
Profissão e segurança Sem papel de informática; mudanças como configuração de TI Contribuição clínica inconsistente; casos de segurança irregulares CCIO/CNIO responsável; toda mudança sob DCB0129/0160 Completude dos casos de segurança e fechamento de perigos acompanhados e assegurados como métricas geridas Função madura de informática conduzindo a melhoria e o compartilhamento de conhecimento

Lista de verificação#

  • Toda regra, conjunto de pedidos e modelo de apoio à decisão tem um responsável clínico nomeado, uma base de evidências, um histórico de versões e uma data de revisão.
  • Um grupo permanente de governança de conteúdo clínico autoriza, revê e aposenta o conteúdo num cronograma baseado em risco.
  • Os alertas são escalonados por gravidade, com a interrupção proporcional ao que está em jogo clinicamente e paradas obrigatórias reservadas ao perigo raro e catastrófico.
  • As taxas de anulação são monitoradas por regra, especialidade e papel, e as regras mais ruidosas são ativamente aposentadas, estreitadas ou rebaixadas.
  • O apoio à decisão é projetado e testado com clínicos da linha de frente no fluxo de trabalho real antes da entrada em produção.
  • Toda nova regra e mudança passa por um caso de segurança clínica sob a DCB0129/DCB0160, com a aprovação de um responsável pela segurança clínica.
  • Um CCIO, CNIO ou equivalente é responsável pelo conteúdo clínico, apoiado por clínicos treinados em informática.
  • Os clínicos podem anular com facilidade significativa, e existe uma via para relatar um alerta errado, ausente ou danoso.
  • A eficácia é avaliada frente a decisões e desfechos mudados, e não a contagens de disparo, com atenção às consequências não intencionais.
  • A fronteira com o apoio baseado em IA/AM é explícita, e quaisquer componentes estatísticos ou de aprendizado são governados sob a governança de IA (ver Tópico 8.4).

Fontes-chave#

  • NHS England / NHS Digital — normas de segurança clínica DCB0129 (fabricação de sistemas de TI em saúde) e DCB0160 (implantação de sistemas de TI em saúde) e orientações para o responsável pela segurança clínica.
  • Faculty of Clinical Informatics — padrões profissionais e o Core Competency Framework para profissionais de informática clínica; definições dos papéis de CCIO e CNIO.
  • Osheroff et al. — Improving Outcomes with Clinical Decision Support: An Implementation Sourcebook (HIMSS) — origem do arcabouço dos "cinco certos" do CDS.
  • NICE — evidências, orientações e o Evidence Standards Framework for Digital Health Technologies; conhecimento acreditado pelo NICE usado como conteúdo de CDS.
  • HL7 International — padrões CDS Hooks e FHIR Clinical Reasoning; a sintaxe Arden para Módulos de Lógica Médica compartilháveis.
  • The Topol Review (Preparing the healthcare workforce to deliver the digital future) — informática clínica na força de trabalho e capacidade.
  • MHRA — orientações sobre software e inteligência artificial como dispositivo médico, para o apoio que cruza o limiar regulatório.

Referências#

  1. Clinical decision support system — Wikipedia — https://en.wikipedia.org/wiki/Clinical_decision_support_system
  2. Health informatics — Wikipedia — https://en.wikipedia.org/wiki/Health_informatics
  3. Alarm fatigue — Wikipedia — https://en.wikipedia.org/wiki/Alarm_fatigue
  4. Computerized physician order entry — Wikipedia — https://en.wikipedia.org/wiki/Computerized_physician_order_entry
  5. Clinical pathway — Wikipedia — https://en.wikipedia.org/wiki/Clinical_pathway
  6. Medical algorithm — Wikipedia — https://en.wikipedia.org/wiki/Medical_algorithm
  7. Medical guideline — Wikipedia — https://en.wikipedia.org/wiki/Medical_guideline
  8. Evidence-based medicine — Wikipedia — https://en.wikipedia.org/wiki/Evidence-based_medicine
  9. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
  10. Sociotechnical system — Wikipedia — https://en.wikipedia.org/wiki/Sociotechnical_system
  11. Arden syntax — Wikipedia — https://en.wikipedia.org/wiki/Arden_syntax
  12. Machine learning — Wikipedia — https://en.wikipedia.org/wiki/Machine_learning
  13. Computer-aided diagnosis — Wikipedia — https://en.wikipedia.org/wiki/Computer-aided_diagnosis
  14. Knowledge management — Wikipedia — https://en.wikipedia.org/wiki/Knowledge_management
  15. NHS England — Clinical Risk Management Standards DCB0129 and DCB0160 — NHS England — https://www.england.nhs.uk/long-read/clinical-risk-management-standards/
  16. Faculty of Clinical Informatics — Core Competency Framework and professional standards — FCI — https://facultyofclinicalinformatics.org.uk/
  17. National Institute for Health and Care Excellence — Evidence Standards Framework for Digital Health Technologies — NICE — https://www.nice.org.uk/about/what-we-do/our-programmes/evidence-standards-framework-for-digital-health-technologies
  18. Health Level Seven International — CDS Hooks and FHIR Clinical Reasoning — HL7 — https://cds-hooks.hl7.org/
  19. Health Education England — The Topol Review: Preparing the healthcare workforce to deliver the digital future — NHS — https://topol.hee.nhs.uk/
  20. Medicines and Healthcare products Regulatory Agency — Software and AI as a Medical Device — GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device

Editar esta página no GitHub — o livro é a fonte da verdade; este site apenas o exibe.