CDS Hooks: Suporte à Decisão Clínica Integrado ao Fluxo de Trabalho

Sistemas de suporte à decisão clínica podem contribuir para que profissionais de saúde identifiquem riscos, avaliem alternativas terapêuticas e acessem recomendações baseadas em evidências.

Entretanto, existe um desafio importante: ‘Como apresentar esse suporte no momento adequado, sem exigir que o profissional interrompa o atendimento, procure outra aplicação ou consulte manualmente diferentes fontes de informação?’

O CDS Hooks foi desenvolvido para responder a esse desafio.

O que é o CDS Hooks?

O CDS Hooks é uma especificação que estabelece um padrão baseado em eventos, chamados de hooks, para integrar serviços de apoio à decisão clínica ao fluxo de trabalho dos sistemas de Registro Eletrônico em Saúde.

Por meio desse padrão, determinadas atividades realizadas durante o atendimento podem acionar automaticamente um serviço de apoio à decisão. Esse serviço analisa o contexto recebido e retorna orientações que podem ser apresentadas diretamente na interface utilizada pelo profissional.

A especificação utiliza APIs RESTful e estruturas JSON transmitidas por HTTPS para viabilizar a comunicação entre dois componentes principais:

CDS Client: sistema que identifica o evento clínico e solicita o apoio à decisão. Geralmente, esse papel é desempenhado por um sistema de registro eletrônico em saúde.

CDS Service: serviço externo que processa as informações recebidas e retorna recomendações, orientações ou ações sugeridas.

O objetivo não é substituir o julgamento clínico, mas disponibilizar informações relevantes no momento e no contexto em que uma decisão está sendo tomada.

Como funciona?

O processo começa quando uma atividade específica ocorre no fluxo de trabalho clínico.

Alguns exemplos de hooks são:

• patient-view: acionado quando o registro de um paciente é aberto;
• order-select: acionado quando uma ou mais ordens clínicas são selecionadas;
• order-sign: acionado imediatamente antes da assinatura de uma ou mais ordens clínicas.

No order-select, por exemplo, o apoio à decisão pode avaliar um medicamento, exame, procedimento ou outra ordem que esteja sendo selecionada.

O order-sign ocorre em uma etapa posterior, quando as informações necessárias para finalizar as ordens geralmente já foram preenchidas e o profissional está prestes a assiná-las.

De maneira simplificada, o funcionamento pode ser representado pelas seguintes etapas:

1. Um evento ocorre no sistema clínico

O profissional abre o registro de um paciente, seleciona uma ordem clínica ou prepara-se para assinar uma ou mais solicitações.

2. O CDS Client identifica o hook

O sistema identifica o evento e verifica quais serviços de apoio à decisão estão registrados para aquele tipo de hook.

3. O CDS Client envia uma requisição

A requisição informa qual hook foi acionado, apresenta o contexto do fluxo clínico e fornece os dados necessários para que o serviço execute sua lógica.

4. O CDS Service processa os dados

O serviço pode avaliar regras clínicas, contraindicações, interações medicamentosas, protocolos assistenciais, critérios de elegibilidade ou outros modelos de decisão.

5. O CDS Service retorna Cards

As orientações são retornadas por meio de cards e apresentadas na interface do sistema clínico. Dependendo do conteúdo, o profissional pode apenas consultar a informação ou interagir com as ações sugeridas.

O contexto clínico

Para produzir uma recomendação relevante, o CDS Service precisa compreender o contexto em que o hook foi acionado.

Esse contexto varia de acordo com cada hook e pode incluir, por exemplo:

• identificação do paciente;
• identificação do profissional;
• encontro assistencial;
• ordens clínicas selecionadas;
• ordens ainda não assinadas;
• informações relacionadas à atividade que está sendo executada.

No patient-view, por exemplo, o contexto pode informar qual paciente está sendo visualizado e qual profissional está acessando seu registro.

No order-select, o contexto pode incluir uma ou mais ordens que estão sendo selecionadas.

Já no order-sign, o contexto pode apresentar o conjunto de ordens que está prestes a ser assinado.

Dessa forma, o contexto não corresponde necessariamente a todo o registro clínico do paciente. Ele representa principalmente as informações relacionadas ao evento que acionou o hook.

O prefetch

Além das informações fornecidas pelo contexto, um CDS Service pode precisar de outros dados clínicos para executar sua lógica.

Para isso, o serviço pode declarar um prefetch template, indicando previamente quais dados gostaria de receber do CDS Client.

Com o prefetch, o CDS Client pode realizar consultas ao servidor FHIR e incluir os resultados na própria requisição enviada ao CDS Service.

Em um hook patient-view, por exemplo, o serviço poderia solicitar previamente recursos como:

• Patient;
• Condition;
• MedicationRequest;
• Observation;
• AllergyIntolerance.

Esses dados podem ser utilizados pelo serviço para identificar condições clínicas, medicamentos em uso, alergias, resultados de exames ou outras informações necessárias para produzir a recomendação.

O prefetch pode contribuir para reduzir chamadas adicionais ao servidor FHIR e favorecer uma resposta mais rápida, aspecto especialmente relevante porque o apoio à decisão precisa ser apresentado durante o fluxo de trabalho clínico.

O que são CDS Cards?

As respostas dos serviços de apoio à decisão são apresentadas principalmente por meio de CDS Cards incorporados à interface do CDS Client.

Cada card contém o apoio à decisão produzido pelo CDS Service e pode combinar informações, sugestões de ações e links.

Informação

Um card pode apresentar uma mensagem para leitura, como:

• um alerta sobre uma condição clínica;
• uma recomendação baseada em protocolo;
• uma contraindicação;
• uma informação adicional relevante para a decisão.

Os cards também podem indicar o grau de importância da mensagem por meio de valores como info, warning ou critical.

Sugestão acionável

Um card pode apresentar uma ou mais sugestões que podem ser aceitas pelo profissional.

Essas sugestões podem envolver, por exemplo:

• adicionar uma ordem;
• substituir um medicamento;
• atualizar uma informação;
• excluir uma ordem;
• selecionar uma alternativa terapêutica.

Quando o profissional aceita uma sugestão, o CDS Client pode aplicar a ação correspondente à sua interface.

As ações propostas podem envolver a criação, atualização ou exclusão de recursos, dependendo do contexto e das funcionalidades implementadas pelo CDS Client.

É importante observar que o CDS Service apenas propõe a recomendação. Cabe ao CDS Client determinar como o card será apresentado e como a interação do usuário será incorporada ao sistema.

Link para conteúdo ou aplicação

O card também pode apresentar um link para:

• uma fonte de referência;
• uma diretriz clínica;
• um conteúdo complementar;
• uma página externa;
• uma aplicação especializada.

Esse recurso é útil quando a orientação exige uma interação mais detalhada do que aquela que pode ser apresentada diretamente no card.

Feedback e melhoria contínua

Um CDS Service também pode disponibilizar um endpoint de feedback.

Por meio dele, o CDS Client pode informar ao serviço o que ocorreu após a apresentação de um card.

O profissional pode, por exemplo:

• aceitar uma sugestão;
• ignorar o card;
• substituir a recomendação por outra decisão;
• informar o motivo pelo qual a orientação não foi seguida.

Essas informações podem ser utilizadas para:

• avaliar a utilidade das recomendações;
• acompanhar a aceitação das sugestões;
• identificar alertas frequentemente ignorados;
• revisar regras pouco específicas;
• reduzir a fadiga de alertas;
• melhorar continuamente o serviço.

O feedback permite acompanhar interações como a aceitação ou a substituição de uma orientação, embora o CDS Hooks não determine como os cards devem permanecer ou ser gerenciados na interface do sistema.

O uso dessas informações deve estar associado a critérios adequados de governança, segurança, auditoria, privacidade e avaliação clínica.

Interoperabilidade não garante relevância clínica

CDS Hooks possibilita que serviços externos de apoio à decisão sejam acionados a partir de atividades realizadas dentro do fluxo de trabalho clínico.

Contudo, a integração técnica não garante, isoladamente, que uma recomendação seja:

• clinicamente válida;
• baseada em dados atualizados;
• adequada ao contexto;
• suficientemente específica;
• segura;
• compreensível;
• apresentada no momento correto.

Uma implementação de CDS Hooks precisa considerar não apenas a comunicação entre os sistemas, mas também:

• qualidade dos dados;
• governança clínica;
• terminologias padronizadas;
• validação das regras;
• rastreabilidade das recomendações;
• desempenho;
• segurança;
• experiência do usuário;
• risco de fadiga de alertas.

O apoio à decisão precisa ser apresentado com rapidez suficiente para não interromper o fluxo de trabalho, mas também com informações confiáveis e adequadas à situação clínica.

Segurança e confiança

Durante uma chamada CDS Hooks, informações clínicas sensíveis podem ser transmitidas entre o CDS Client e o CDS Service.

Dependendo da implementação, o CDS Service também pode receber uma autorização temporária para consultar dados adicionais em um servidor FHIR.

Por esse motivo, a implementação deve considerar:

• comunicação protegida por HTTPS;
• autenticação entre os participantes;
• autorização com escopo mínimo;
• uso de tokens temporários;
• seleção de serviços confiáveis;
• proteção dos dados clínicos;
• auditoria das chamadas;
• rastreabilidade das recomendações.

O CDS Client é responsável por avaliar a segurança, a integridade e a adequação dos serviços que utiliza. Os tokens concedidos aos serviços devem ser específicos, temporários e limitados aos dados necessários.

Além disso, é necessário avaliar os riscos associados a recomendações incorretas, dados desatualizados, serviços não confiáveis e links potencialmente perigosos apresentados nos cards.

CDS Hooks não é apenas um sistema de alertas

Embora alertas sejam um de seus possíveis usos, limitar CDS Hooks a notificações seria uma simplificação.

A especificação pode apoiar diferentes cenários, como:

• verificação de interações medicamentosas;
• identificação de contraindicações;
• recomendação de doses;
• adequação de exames de imagem;
• identificação de critérios de elegibilidade;
• prevenção de duplicidade de solicitações;
• orientação baseada em protocolos clínicos;
• recomendação de alternativas terapêuticas;
• identificação de lacunas assistenciais;
• direcionamento para conteúdos ou aplicações especializadas.

O aspecto central é que o apoio à decisão seja acionado a partir de um evento significativo do fluxo de trabalho e apresentado no momento em que ainda pode contribuir para a decisão do profissional.

Conclusão

CDS Hooks aproxima o apoio à decisão clínica do ponto em que ele pode gerar maior valor: o momento da decisão.

Por meio de eventos padronizados, atividades realizadas no sistema clínico podem acionar serviços externos capazes de analisar o contexto e retornar informações, sugestões ou links diretamente no fluxo de trabalho.

No entanto, o valor dessa abordagem não está em apresentar uma quantidade maior de alertas.

Está em oferecer recomendações:

• confiáveis;
• compreensíveis;
• acionáveis;
• relevantes para o contexto;
• apresentadas no momento adequado;
• integradas ao trabalho do profissional.

Mais do que conectar um serviço a um sistema de Registro Eletrônico em Saúde, implementar CDS Hooks significa responder a uma questão essencial:

Qual informação deve ser apresentada, para qual profissional e em qual momento do cuidado?

---

Para conhecer e experimentar

Especificação e documentação: https://cds-hooks.org/

Repositório da especificação: https://github.com/cds-hooks/docs/

Sandbox: http://sandbox.cds-hooks.org/