Tópico 1.6 — Segurança clínica e gestão de riscos

Em uma frase: A segurança clínica é a prática disciplinada e comprovada de encontrar as formas pelas quais a sua tecnologia digital poderia prejudicar um paciente e de controlar esses perigos antes que cheguem a alguém — segurança projetada desde o primeiro esboço, e não acrescentada antes da entrada em produção.

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

Na maioria dos setores, um defeito de software é um incômodo: uma página não carrega, um pedido é duplicado, um relatório atrasa. Na saúde e nos cuidados, a mesma classe de defeito pode matar. Um campo de medicação que trunca uma vírgula decimal, uma tela de resultados que mostra o paciente errado, um algoritmo de triagem que silenciosamente deixa de sinalizar um sintoma, uma integração que descarta em silêncio os registros de alergia — cada um é um bug de software e, ao mesmo tempo, um perigo clínico capaz de causar dano grave ou morte. É por isso que a segurança clínica não é um refinamento de qualidade posto sobre uma boa engenharia; é uma disciplina distinta e regulada, com padrões, papéis e evidências próprios.

O que está em jogo é assimétrico e, muitas vezes, invisível. Quando um sistema digital funciona, ninguém vê o dano que ele evitou; quando falha, o dano pode ser catastrófico, tardio e distribuído por milhares de pacientes antes que alguém note um padrão. Essa combinação — alta consequência, baixa visibilidade, grande raio de impacto — significa que você não pode contar com os usuários para pegar os problemas nem com os incidentes para ensinar tudo. É preciso raciocinar sobre o dano de forma proativa, antes da implantação, e continuar raciocinando enquanto o sistema está em produção. No Reino Unido, esse raciocínio proativo não é opcional: espera-se, por contrato e profissionalmente, que as organizações do NHS e seus fornecedores apliquem normas nacionais de gestão de riscos clínicos e consigam mostrar o seu trabalho. Acertar isso é indissociável das evidências (ver Tópico 1.3 — Decisões baseadas em evidências), da governança da informação e da cibersegurança (ver Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança) e de como você opera os serviços depois de entrarem em produção (ver Tópico 3.8 — Gestão de serviços e operação em produção).

Conceitos centrais#

Segurança do paciente e gestão de riscos. A segurança do paciente é a prevenção, a redução, o relato e a análise de danos aos pacientes decorrentes do cuidado. A gestão de riscos clínicos aplica a disciplina geral da gestão de riscos — identificar, avaliar, priorizar e controlar riscos — à pergunta específica de como um sistema de TI em saúde poderia contribuir para o dano ao paciente. As duas normas nacionais que regem isso na Inglaterra são a DCB0129 e a DCB0160 (DCB significa Data Coordination Board; são normas do Standardization Committee for Care Information / SCCI, tornadas obrigatórias pela Health and Social Care Act 2012). A DCB0129 impõe obrigações ao fabricante ou fornecedor de um sistema de TI em saúde; a DCB0160 impõe obrigações à organização de saúde que o implanta e usa. São complementares: o caso de segurança limpo de um fornecedor não cumpre o dever de um hospital que implanta de avaliar os perigos introduzidos pela sua própria configuração, fluxo de trabalho e contexto.

O Responsável pela Segurança Clínica (CSO). Ambas as normas exigem um Responsável pela Segurança Clínica nomeado, devidamente qualificado e experiente — um clínico registrado, em exercício, que tenha concluído um treinamento reconhecido em segurança clínica — para responder pela atividade de gestão de riscos clínicos e aprovar pessoalmente o caso de segurança. O papel de CSO é uma exigência de competência, e não um título que se possa atribuir a quem estiver livre. O CSO atesta que os perigos foram identificados e controlados a um nível aceitável; é um julgamento profissional que carrega responsabilização profissional.

Os artefatos de gestão de riscos clínicos. Três documentos ancoram a disciplina. O arquivo de gestão de riscos clínicos é o recipiente de toda a evidência de segurança de um sistema. O registro de perigos (hazard log) é o cadastro vivo de cada perigo identificado, suas causas, consequências, classificação de risco, controles e risco residual. O caso de segurança clínico é o argumento estruturado, sustentado por evidências, de que o sistema é aceitavelmente seguro para o uso pretendido no contexto pretendido — acompanhado de um relatório do caso de segurança que resume o argumento para aprovação. Não são papelada por si mesma; são o modo de tornar o raciocínio de segurança explícito, revisável e durável.

Análise de perigos: identificação, análise, avaliação, controle. O ciclo central é: identificação de perigos (imaginar sistematicamente como o sistema poderia contribuir para o dano — por meio de oficinas, percursos clínicos, análise de modos de falha), análise de risco (estimar a gravidade do dano e a probabilidade de ele ocorrer), avaliação de risco (comparar o risco estimado com critérios de aceitabilidade) e controle de risco (introduzir medidas — mudanças de projeto, alertas, treinamento, procedimentos — para reduzir o risco inaceitável e, depois, reavaliar o risco residual). O risco é reduzido ao mínimo razoavelmente praticável (ALARP): você continua controlando até que reduzir mais seja grosseiramente desproporcional ao benefício obtido.

Regulação de dispositivos médicos, o MHRA e o Software como Dispositivo Médico (SaMD). Algumas tecnologias de saúde digital são dispositivos médicos regulados. O software com finalidade médica — diagnosticar, prevenir, monitorar, prever, tratar — pode ser, ele próprio, um dispositivo médico: o Software como Dispositivo Médico (SaMD). No Reino Unido, a Medicines and Healthcare products Regulatory Agency (MHRA) regula os dispositivos médicos, incluindo o SaMD, e a norma de ciclo de vida de software IEC 62304 rege como esse software deve ser desenvolvido. Decidir se a sua tecnologia é um dispositivo regulado é uma pergunta de limiar com grandes consequências, e é separada da gestão de riscos clínicos DCB0129/0160, embora corra ao lado dela.

O Digital Technology Assessment Criteria (DTAC). O DTAC é a linha de base nacional que as organizações de saúde e de cuidados sociais do NHS usam para avaliar produtos digitais antes da aquisição, cobrindo segurança clínica (evidência de conformidade com a DCB0129), proteção de dados, segurança técnica, interoperabilidade e usabilidade. Não substitui a gestão de riscos clínicos; verifica que o fornecedor a fez.

Fatores humanos e cultura de segurança. Os fatores humanos (ergonomia) são o estudo científico de como as pessoas interagem com os sistemas em condições reais — fadiga, interrupção, carga cognitiva, fadiga de alarmes. A maior parte do dano digital surge não de código "errado", mas de projetos que tornam difícil a ação segura e fácil a insegura. A cultura de segurança é o compromisso organizacional de trazer à tona, relatar e aprender com o risco sem culpar — a diferença entre uma equipe que esconde quase-acidentes e outra que os explora para melhorar.

Relato de incidentes e aprendizado. Na Inglaterra, o Learn from Patient Safety Events (LFPSE) é o serviço nacional de registro de eventos de segurança do paciente, e o Patient Safety Incident Response Framework (PSIRF) define como as organizações do NHS respondem aos incidentes e aprendem com eles — enfatizando a análise de causa-raiz proporcional e baseada em sistemas em vez da culpa. Os sistemas em produção geram novos perigos; por isso a segurança clínica continua depois da entrada em produção, com o retorno dos incidentes ao registro de perigos.

Boas práticas#

1. Nomeie um Responsável pela Segurança Clínica competente e dê-lhe autoridade real. Nomeie um clínico registrado, em exercício e com treinamento reconhecido em segurança clínica como CSO de cada sistema no escopo e garanta que a sua aprovação seja uma barreira genuína, e não um carimbo obtido na véspera do lançamento. O CSO precisa poder dizer "ainda não" e ser ouvido — o que significa proteger seu tempo, sua independência e sua posição perante o conselho do programa. Um CSO desautorizado pela pressão de entrega é uma ficção de governança.

2. Faça a identificação de perigos cedo, com clínicos na sala. Comece as oficinas de perigos na descoberta e no projeto, e não antes da entrada em produção, porque os controles mais baratos e eficazes são mudanças de projeto feitas antes de qualquer construção (ver Tópico 3.5 — Ciclos de vida de entrega). Traga clínicos da linha de frente, e não apenas analistas, porque eles sabem como o trabalho realmente acontece — as interrupções, as gambiarras, o modo como uma tela é lida às 3 da manhã. Percorra cenários clínicos realistas e pergunte sem descanso: "como este sistema poderia contribuir para que um paciente fosse prejudicado?"

3. Mantenha um registro de perigos vivo, e não um documento do dia do lançamento. Trate o registro de perigos como um cadastro permanente que se abre na descoberta e nunca se fecha enquanto o sistema estiver em produção. Cada perigo registra suas causas, o dano potencial, a classificação de risco inicial, os controles aplicados e o risco residual após os controles. Quando um incidente, uma mudança ou um quase-acidente revela um novo perigo, ele entra no registro e percorre o mesmo ciclo — o registro é a memória do seu raciocínio de segurança.

4. Faça a organização que implanta assumir a DCB0160, mesmo com um fornecedor conforme. O caso de segurança DCB0129 de um fornecedor cobre o produto como construído; não pode cobrir como você o configura, que fluxos de trabalho envolve em torno dele ou quais das suas populações o usam. Conduza a sua própria avaliação DCB0160 para os perigos locais — integração com seus outros sistemas, a qualidade dos seus dados, suas vias clínicas — e mantenha o seu próprio registro de perigos. Presumir que a garantia do fornecedor cobre o seu contexto é um atalho comum e perigoso.

5. Torne o controle de riscos proporcional e prefira o projeto aos avisos. Classifique os controles por força: eliminar o perigo no projeto (restrições, padrões, funções de forçamento) supera um alerta na tela, que supera uma linha num manual de treinamento. Reserve a garantia mais pesada para os perigos de maior consequência e aplique processo mais leve e rápido às mudanças genuinamente de baixo risco — a proporcionalidade é o que permite à segurança acompanhar o ritmo da entrega. Reduza o risco ao ALARP e registre por que o risco residual é aceitável.

6. Projete para os fatores humanos e respeite a fadiga de alarmes. Parta do princípio de que os usuários estão ocupados, interrompidos e reconhecendo padrões, e projete de modo que a ação segura seja a ação fácil e padrão. Proteja-se da sobrecarga de alertas: um alerta que dispara demais é ignorado, de modo que cada aviso adicional precisa merecer o seu lugar, ou degrada os que importam. O teste de usabilidade em condições realistas é uma atividade de segurança clínica, e não apenas um refinamento de design.

7. Determine deliberadamente o seu status regulatório. Pergunte cedo se o seu software atende à definição de dispositivo médico ou de SaMD e, se atender, envolva as exigências do MHRA e a IEC 62304 desde o início, em vez de descobrir a obrigação tarde. Errar a classificação é caro nas duas direções — um dispositivo não registrado é uma falha legal e de segurança, enquanto superclassificar uma ferramenta simples desperdiça capacidade de garantia escassa. Na dúvida, busque aconselhamento regulatório e documente o raciocínio.

8. Use o DTAC como piso, e não como linha de chegada. Trate o Digital Technology Assessment Criteria como a verificação mínima de entrada para qualquer produto digital adquirido, confirmando que segurança clínica, proteção de dados, segurança, interoperabilidade e usabilidade foram tratadas. Passar no DTAC significa que o fornecedor fez o trabalho; não significa que o produto é seguro no seu contexto; portanto, combine-o com a sua própria avaliação DCB0160 e o monitoramento em produção.

9. Feche o ciclo dos incidentes em produção até o registro de perigos. Ligue o seu relato de incidentes — envios ao LFPSE, investigações PSIRF, relatos locais de quase-acidentes — de volta à gestão de riscos clínicos, de modo que o dano real e os quase-acidentes atualizem seus perigos e controles. Um caso de segurança que nunca é revisitado após a entrada em produção apodrece, porque os sistemas em produção, as integrações e a prática clínica derivam (ver Tópico 3.8 — Gestão de serviços e operação em produção). O aprendizado é baseado em sistemas e atento à culpa, não uma busca por alguém a punir.

10. Construa uma cultura de segurança justa e de relato. Torne seguro e esperado relatar quase-acidentes e questionar um lançamento por razões de segurança, porque os perigos de que você nunca ouve falar são perigos que não pode controlar. Os líderes dão esse tom respondendo a más notícias com curiosidade e melhoria em vez de culpa e tratando a cautela do CSO como valiosa, e não como obstrutiva. A cultura é o substrato do qual depende toda outra prática aqui.

Perguntas para discutir com a sua equipe#

1. Onde, no nosso portfólio atual, estamos contando com a garantia de segurança de um fornecedor para cobrir riscos que na verdade são nossos? Esta pergunta sonda a divisão DCB0129/DCB0160, que as equipes rotineiramente borram. O caso de segurança DCB0129 de um fornecedor trata do produto como fabricado, mas, no momento em que você o configura, o conecta a seus outros sistemas, envolve fluxos de trabalho locais em torno dele e o aponta para a sua população específica de pacientes, você introduz perigos que o fornecedor nunca avaliou e não poderia ter avaliado. A tensão honesta é que conduzir a sua própria avaliação DCB0160 custa tempo clínico e analítico escasso, e é tentador tratar a garantia limpa de um fornecedor e uma aprovação no DTAC como suficientes. Percorram uma implantação em andamento ou iminente e perguntem de forma concreta: quem é o nosso CSO nomeado para ela, temos o nosso próprio registro de perigos e quais perigos surgem puramente do nosso contexto local, e não do produto em si? Uma boa resposta nomeia sistemas específicos em que a avaliação local é frágil, distingue os perigos do produto dos perigos da implantação e se compromete a assumir estes últimos, em vez de presumir que estão cobertos.

2. Quão proporcional é o nosso processo de segurança clínica — estamos enterrando mudanças de baixo risco em papelada enquanto mudanças de alta consequência passam por inércia? O tópico defende que a garantia deve acompanhar o risco clínico: o escrutínio mais pesado para os perigos de maior consequência, processo mais leve e rápido onde o risco é genuinamente baixo. Esta pergunta testa se a sua organização de fato calibra ou aplica um único ajuste grosseiro. As duas direções de falha são reais e custosas — um processo uniformemente pesado ensina as equipes a ver a segurança clínica como um imposto burocrático e a contorná-lo, enquanto um processo uniformemente leve deixa uma mudança numa calculadora de dosagem de medicamento passar com o mesmo esforço que uma mudança numa página de ajuda. O perigo mais sutil é que a inércia, e não o risco, decida o escrutínio: um programa emblemático com a atenção da diretoria pode adquirir uma aura de inevitabilidade que desencoraja o CSO de dizer "ainda não". Examinem duas ou três mudanças recentes de risco claramente distinto e perguntem se o esforço despendido correspondeu ao potencial de dano e se alguém se sentiu em condições de frear a de maior visibilidade. Uma resposta honesta admite onde o processo está mal calibrado em qualquer direção e trata a proporcionalidade como um julgamento defensável e explícito, e não como um reflexo.

3. Quando algo quase deu errado com um dos nossos sistemas digitais, o que realmente aconteceu depois — e um clínico da linha de frente diria que era seguro levantar o assunto? Esta pergunta examina a cultura de segurança e o ciclo de aprendizado com incidentes, que é onde os compromissos declarados encontram a realidade. A segurança clínica depende de ouvir falar dos quase-acidentes, mas as pessoas só relatam quando relatar parece seguro e útil e quando veem isso levar a mudanças, e não à culpa. A tensão é que, sob pressão de entrega e reputacional, o instinto é explicar o quase-acidente, encerrá-lo depressa e seguir em frente — sobretudo se trazê-lo plenamente à tona atrasasse um lançamento ou constrangesse um patrocinador sênior. A abordagem do PSIRF, baseada em sistemas e atenta à culpa, existe justamente porque procurar um indivíduo a culpar suprime o relato de que você precisa e deixa de ver as causas reais e sistêmicas. Baseiem a discussão num quase-acidente ou incidente recente específico: foi registrado, chegou ao registro de perigos, foi feita uma investigação proporcional e algo de fato mudou? Uma boa resposta é franca sobre se o relato pareceu seguro, distingue o aprendizado genuíno do encerramento burocrático e nomeia comportamentos concretos que os líderes adotarão para que a próxima pessoa que perceber um perigo fale.

4. Determinamos com honestidade quais dos nossos produtos são dispositivos médicos regulados — e quem responde por essa decisão? O status regulatório é uma pergunta de limiar com consequências desproporcionais, e é fácil deixá-la sem resposta porque respondê-la pode ser inconveniente. O software que diagnostica, prevê, monitora ou trata pode ser, ele próprio, Software como Dispositivo Médico, atraindo as obrigações do MHRA e a norma de ciclo de vida IEC 62304 — separadas da gestão de riscos clínicos DCB0129/0160 e adicionais a ela. A tensão corre nos dois sentidos: subclassificar deixa você entregando um dispositivo não registrado, uma falha legal e de segurança que pode vir à tona de modo catastrófico em escala, enquanto superclassificar uma ferramenta administrativa simples queima capacidade de garantia escassa de que você precisava em outro lugar. O perigo é que a classificação caia entre papéis — os clínicos presumem que os engenheiros decidiram, os engenheiros presumem que a equipe regulatória ou comercial decidiu, e ninguém de fato registrou o raciocínio. Olhem de forma concreta os produtos do seu portfólio mais próximos do limite — qualquer coisa com uma regra de triagem, uma pontuação de risco, um algoritmo de alerta — e perguntem quem fez a determinação do dispositivo, com que base e se ela está documentada e é revisitada à medida que as funcionalidades mudam. Uma resposta honesta nomeia os produtos limítrofes, aponta uma justificativa registrada e defensável para cada um e é franca onde a decisão nunca foi de fato tomada.

5. Estamos eliminando perigos no projeto, ou estamos acumulando silenciosamente alertas e avisos que os nossos clínicos já aprenderam a ignorar? O tópico classifica os controles por força — eliminar o perigo no projeto supera um alerta na tela, que supera uma linha num manual de treinamento —, mas os alertas são o caminho de menor resistência, porque acrescentar um aviso é rápido e parece responsável, enquanto redesenhar um fluxo de trabalho é lento e contestado. Com o tempo, esse viés se acumula em fadiga de alarmes: tantos avisos disparam que os clínicos passam por todos eles no automático, inclusive o que importa, de modo que cada novo alerta pode, na verdade, reduzir a segurança. A tensão real é que todo alerta desnecessário tem um patrocinador que o acrescentou de boa-fé após algum incidente, o que torna os avisos politicamente difíceis de remover mesmo quando degradam o sistema. Os fatores humanos são a disciplina aqui — projetar de modo que a ação segura seja a ação fácil e padrão para um usuário ocupado e interrompido que lê uma tela às 3 da manhã — e o teste de usabilidade em condições realistas é uma atividade de segurança clínica, não um refinamento de design. Examinem um sistema que suas equipes de fato usam e perguntem quantos alertas um clínico encontra numa tarefa típica, quais deles realmente mudam o comportamento e onde uma função de forçamento ou um padrão melhor poderia ter substituído por completo um aviso. Uma boa resposta resiste ao reflexo de acrescentar mais um alerta, trata a carga de alertas como um perigo mensurável por si só e está disposta a remover avisos que deixaram de merecer o lugar.

6. À medida que nossos sistemas em produção, integrações e vias clínicas derivam ao longo do tempo, como sabemos que o nosso caso de segurança ainda se sustenta? A segurança clínica não termina na entrada em produção; os sistemas em produção geram novos perigos, e o mundo ao redor de um sistema continua se movendo — uma integração a montante muda seus dados, uma via clínica é redesenhada, um fornecedor lança uma atualização, uma nova coorte de pacientes passa a usar a ferramenta. Um caso de segurança aprovado há dois anos descreve um sistema e um contexto que talvez já não existam; a pergunta, então, é se o seu registro de perigos é um cadastro vivo ou um documento assinado uma vez e deixado a apodrecer (ver Tópico 3.8 — Gestão de serviços e operação em produção). A tensão é que manter o raciocínio de segurança após o lançamento compete com a nova entrega pelo mesmo tempo escasso de CSO e de clínicos, e a deriva é gradual e invisível de um modo que raramente chama atenção até que algo falhe. Ângulos concretos incluem o controle de mudanças que reaciona a avaliação de perigos quando a configuração ou as integrações mudam, a revisão periódica dos perigos de maior consequência e um monitoramento que realmente detectaria um controle se degradando em silêncio. Escolham um sistema em produção há um ano ou mais e perguntem quando seus perigos foram revistos pela última vez, o que mudou por baixo dele desde a aprovação e quem perceberia se um controle essencial parasse de funcionar. Uma resposta honesta distingue os sistemas com genuína gestão contínua de segurança dos que seguem na inércia de um caso de segurança obsoleto e se compromete com uma cadência proporcional de revisão atrelada a mudanças reais, e não só ao calendário.

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

Um sistema de cuidados integrados (ICS) está implantando uma ferramenta compartilhada de encaminhamento eletrônico que permite aos clínicos gerais encaminhar pacientes diretamente a serviços comunitários, com um conjunto de regras de triagem embutido que direciona os casos urgentes para uma fila mais rápida. Uma abordagem movida pela entrega pegaria o caso de segurança DCB0129 do fornecedor, passaria no DTAC e entraria em produção para cumprir uma data prometida ao conselho.

Em vez disso, o programa nomeia um clínico geral em exercício, com treinamento em segurança clínica, como Responsável pela Segurança Clínica e abre um arquivo de gestão de riscos clínicos e um registro de perigos no início do projeto. Oficinas de perigos precoces com clínicos gerais, enfermeiros comunitários e administrativos trazem à tona vários perigos que o caso de nível de produto do fornecedor jamais tocou — todos decorrentes da implantação local. O pior: as regras de triagem foram configuradas com base nas definições de serviço do próprio ICS e um erro de mapeamento poderia direcionar um encaminhamento urgente de câncer de pele para uma fila rotineira de dermatologia, com espera de várias semanas. Esse perigo é classificado como de gravidade alta e probabilidade plausível.

Percorrendo o ciclo de controle de riscos, a equipe prefere o projeto aos avisos. Acrescenta uma função de forçamento para que uma sinalização clínica urgente não possa ser ignorada silenciosamente pela lógica de roteamento, um relatório de reconciliação que um clínico revisa diariamente e — o mais baixo na hierarquia — uma nota de treinamento. O risco residual é reclassificado e julgado aceitável e ALARP; o CSO registra o porquê. Como a ferramenta apenas roteia e não diagnostica por si, a equipe avalia que ela não atinge o limiar de SaMD, documenta esse raciocínio e o arquiva. O teste de fatores humanos pega um problema separado: um alerta excessivamente zeloso de "encaminhamento duplicado" dispara com tanta frequência que os clínicos gerais já o ignoram; por isso ele é redesenhado para disparar apenas em duplicatas genuínas.

Na entrada em produção, o caso de segurança DCB0160 é aprovado pelo CSO, e não pelo diretor do programa. Três semanas depois, um relato ao LFPSE e um quase-acidente sinalizado por um recepcionista revelam um novo perigo — um campo de texto livre sendo usado para introduzir informação urgente que o roteamento nunca vê. Sob o PSIRF, é conduzida uma revisão proporcional e baseada em sistemas, o perigo entra no registro, uma mudança de projeto é agendada e um controle provisório é comunicado na mesma semana. O caso de segurança é um argumento vivo, e o registro mostra exatamente como cada perigo foi raciocinado — que é o que um inspetor, um legista ou um novo CSO, daqui a dois anos, precisará.

Perspectivas setoriais#

Todos devem o mesmo dever de controlar o risco clínico, mas a maquinaria, os incentivos e as pressões diferem muito conforme a organização.

Startup#

Uma startup de saúde digital frequentemente encontra a segurança clínica como uma barreira de aquisição: um comprador do NHS pede o DTAC e um caso de segurança DCB0129, e há uma correria. A jogada vencedora é incorporar a gestão de riscos clínicos desde o primeiro sprint — um registro de perigos ao lado do backlog, um Responsável pela Segurança Clínica acessível (muitas vezes contratado e não empregado, mas genuinamente competente e empoderado) — porque retroajustar um caso de segurança a um produto pronto é lento, caro e pouco convincente. Os fundadores também devem enfrentar a questão do SaMD com honestidade e cedo, já que descobrir no meio da escala que o produto é um dispositivo médico não registrado é um risco legal e de segurança existencial. Bem feitos, os artefatos maduros de segurança clínica se tornam um ativo comercial que encurta os ciclos de venda ao NHS.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso, uma agência de cuidados domiciliares, uma clínica de unidade única ou um pequeno fornecedor de tecnologia em saúde que já passou da fase pré-receita — carrega o mesmo dever DCB0160 de um grande hospital quando implanta e configura sistemas digitais, mas sem nenhuma capacidade sobrando para cumpri-lo. Raramente há um CSO ou analista de segurança dedicado na folha, de modo que a via prática é contratar um clínico competente e em exercício em regime de prestação de serviços e manter um registro de perigos enxuto, mas genuíno, em vez de fingir que o dever não se aplica. Os perigos locais mais agudos costumam ser os de configuração e de fluxo de trabalho — como o prontuário compartilhado é configurado, como as sinalizações urgentes são tratadas, como a gambiarra de um administrativo de meio período vira um risco de roteamento — precisamente os perigos que o caso DCB0129 de um fornecedor nunca cobre. A proporcionalidade é a amiga do pequeno prestador aqui: concentre o pouco tempo de garantia de que dispõe nos perigos de maior consequência, use o DTAC e o caso de segurança do fornecedor como piso ao escolher produtos e apoie-se em recursos compartilhados, como o apoio de segurança clínica do ICS, em vez de tentar construir sozinho todo o aparato.

Grande organização#

Um hospital do NHS ou um ICS carrega responsabilização dupla: implanta sistemas de terceiros sob a DCB0160 e, muitas vezes, constrói ou configura intensamente os seus próprios sob a DCB0129. A falha característica é institucional — um programa emblemático de prontuário eletrônico cuja data de entrada em produção tem peso político, de modo que a cautela do CSO é tratada em silêncio como um obstáculo. O corretivo é estrutural: dar ao CSO independência e um veto real, manter um registro de perigos vivo em todo o parque, em vez de uma prateleira de documentos do dia do lançamento, e ligar o aprendizado do LFPSE e do PSIRF de volta à gestão de riscos clínicos como processo permanente. Na escala de uma grande organização, os maiores perigos são os de integração e de configuração, que nenhuma garantia de fornecedor cobre; portanto, a apropriação local é inegociável.

Governo#

Um órgão nacional — NHS England, MHRA, DHSC, NICE — define os padrões que os demais devem cumprir, de modo que seus modos de trabalho moldam todo o sistema: a DCB0129/0160, o DTAC e a regulação do SaMD são instrumentos de segurança em escala populacional. As decisões aqui atraem escrutínio regulatório, parlamentar e público, e um sistema imposto nacionalmente que carrega um perigo latente distribui esse dano por milhões antes que alguém veja o padrão. As obrigações são a proporcionalidade tornada explícita em padrões publicados, transparência sobre o risco residual e manter o arcabouço regulatório atualizado à medida que a tecnologia — sobretudo a IA — o ultrapassa (ver Tópico 8.4 — Governança de IA e de tecnologias emergentes). O risco distintivo nessa escala é sistêmico: impor uma tecnologia em todo o parque com base em evidência de segurança frágil consolida um perigo em toda parte ao mesmo tempo.

Modos de falha comuns#

• Segurança acrescentada no fim. Produzir um caso de segurança na semana anterior à entrada em produção para satisfazer uma barreira. Antídoto: abrir o registro de perigos na descoberta; eliminar no projeto os maiores perigos.
• Garantia do fornecedor confundida com segurança local. Tratar um caso DCB0129 e uma aprovação no DTAC como cobrindo a sua implantação. Antídoto: assumir a sua avaliação DCB0160 e o seu registro de perigos local.
• CSO como carimbo. Um Responsável pela Segurança Clínica sem tempo, independência ou autoridade para dizer "ainda não". Antídoto: proteger o papel e fazer da aprovação uma barreira genuína.
• Registro de perigos morto. Um documento escrito uma vez e nunca revisitado após o lançamento. Antídoto: mantê-lo vivo; alimentá-lo com incidentes e mudanças.
• Sobrecarga de alertas. Tantos avisos que os clínicos ignoram todos, inclusive os vitais. Antídoto: projeto com fatores humanos; cada alerta precisa merecer o seu lugar.
• Cultura de culpa. Punir indivíduos por quase-acidentes, de modo que o relato seca. Antídoto: uma cultura justa e baseada em sistemas, alinhada ao PSIRF.
• Limiar regulatório perdido. Entregar SaMD sem reconhecê-lo como dispositivo regulado. Antídoto: avaliar e documentar cedo o status de dispositivo médico.

Modelo de maturidade#

Lista de verificação#

• Um Responsável pela Segurança Clínica competente, em exercício e treinado está nomeado para cada sistema, com tempo e autoridade para dizer "ainda não".
• Um arquivo de gestão de riscos clínicos, um registro de perigos vivo e um caso de segurança clínica existem para cada sistema no escopo.
• A identificação de perigos começou na descoberta, com clínicos da linha de frente na sala.
• A organização que implanta conduziu a sua própria avaliação DCB0160, e não apenas aceitou o caso DCB0129 do fornecedor.
• Os controles de risco preferem eliminação no projeto a alertas e alertas a treinamento, com o risco residual reduzido ao ALARP e justificado.
• O status de dispositivo médico / SaMD foi avaliado e documentado, e as obrigações do MHRA / IEC 62304 foram acionadas quando relevantes.
• O DTAC foi concluído como piso, combinado com a gestão local de riscos clínicos.
• Testes de fatores humanos e de usabilidade em condições realistas foram feitos; a carga de alertas é controlada.
• Os incidentes em produção (LFPSE) e o aprendizado do PSIRF retornam ao registro de perigos como processo permanente.
• Relatar quase-acidentes e questionar um lançamento por razões de segurança é visivelmente seguro e esperado.

Fontes-chave#

• NHS England — DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems.
• NHS England — DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems.
• NHS England — Clinical Safety Officer training e orientações de gestão de riscos clínicos.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• MHRA — orientações Software and Artificial Intelligence (AI) as a Medical Device.
• IEC — IEC 62304: Medical device software — software life cycle processes.
• ISO — ISO 14971: Application of risk management to medical devices.
• NHS England — serviço Learn from Patient Safety Events (LFPSE).
• NHS England — Patient Safety Incident Response Framework (PSIRF).
• Organização Mundial da Saúde — Global Patient Safety Action Plan 2021–2030.

Referências#

1. Patient safety — Wikipedia — https://en.wikipedia.org/wiki/Patient_safety
2. Risk management — Wikipedia — https://en.wikipedia.org/wiki/Risk_management
3. Hazard analysis — Wikipedia — https://en.wikipedia.org/wiki/Hazard_analysis
4. Safety case — Wikipedia — https://en.wikipedia.org/wiki/Safety_case
5. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
7. Ergonomics (human factors) — Wikipedia — https://en.wikipedia.org/wiki/Ergonomics
8. Safety culture — Wikipedia — https://en.wikipedia.org/wiki/Safety_culture
9. As low as reasonably practicable (ALARP) — Wikipedia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
10. Root-cause analysis — Wikipedia — https://en.wikipedia.org/wiki/Root-cause_analysis
11. IEC 62304 — Wikipedia — https://en.wikipedia.org/wiki/IEC_62304
12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan