Capa: imagem editorial do acervo Arkmeds sobre planejamento e análise.
Gerir o ciclo de vida de um produto na saúde significa acompanhar necessidade, desenvolvimento, implantação, uso, mudanças e retirada, com responsáveis e evidências em cada etapa. Para a instituição de saúde, a decisão continua depois da compra: é preciso saber quem usa, quem dá suporte, quais versões estão em operação e como preservar a continuidade do serviço.
Um sistema pode entrar em produção na data combinada e ainda exigir ajustes de treinamento, integração ou suporte. Por isso, a pergunta útil para uma reunião de acompanhamento é: o produto continua resolvendo a necessidade que justificou sua adoção? Este artigo reúne pesquisa, um caso real de correção de software e ferramentas adaptáveis para responder a essa pergunta.
Qual é a diferença entre produto, projeto e ativo?
Na prática de gestão, cada um desses termos define uma unidade diferente de acompanhamento. Um projeto de implantação pode terminar com a entrega aceita; o produto segue em uso. Um ativo é a unidade identificável que a equipe precisa localizar, manter e documentar.
| Unidade de gestão | Exemplo no serviço de saúde | Pergunta de acompanhamento |
|---|---|---|
| Produto | Uma solução de software ou um modelo de dispositivo | A solução atende à necessidade ao longo do tempo? |
| Projeto | Implantação dessa solução em um setor | A entrega foi concluída e aceita dentro do escopo acordado? |
| Ativo | Equipamento identificado no inventário | Qual é seu estado, histórico e responsabilidade de manutenção? |
| Serviço | Processo assistencial apoiado pelo produto | Como a equipe trabalha e mantém a continuidade da assistência? |
Essa distinção evita um problema comum de organização: encerrar o projeto e deixar sem responsável as atualizações, dúvidas dos usuários e decisões de substituição. A passagem da implantação para a operação precisa ser explícita. O termo de aceite pode registrar pendências, suporte, treinamento e a próxima revisão do desempenho em uso.
O que uma pesquisa mostra sobre adoção e suporte?
Greenhalgh et al. (2017) estudaram seis programas no Reino Unido: mais de 400 horas de observação, 165 entrevistas e 200 documentos. O caso E acompanhou dois produtos de organização do cuidado familiar.
| Relato do caso E | Contagem publicada |
|---|---|
| Produto A: famílias identificadas com uso ativo | Menos de 5 |
| Produto B: famílias usando pela organização de cuidadores, à época da redação | Mais de 1.000 |
A não previra treinamento e suporte contínuo; B previa convite e helpdesk. Produtos e contextos diferentes, sem denominador comum: as contagens não isolam o efeito do suporte.
A interpretação para planejamento é combinar suporte e acompanhamento do uso antes da implantação. O estudo não prevê uma taxa de sucesso.
Quais decisões cabem em cada etapa do ciclo de vida?
O mapa abaixo é uma organização editorial adaptável, não um protocolo normativo de desenvolvimento. As etapas podem se sobrepor: uma mudança no uso real pode exigir nova avaliação de risco, treinamento ou validação do fabricante.
- 1 · NecessidadeDefinir problema, usuários e resultado esperado.
- 2 · DesenvolvimentoReunir requisitos e evidências aplicáveis.
- 3 · ImplantaçãoCombinar aceite, suporte e treinamento.
- 4 · UsoAcompanhar ocorrências e resultado em operação.
- 5 · MudançaRegistrar versão, dependências e impacto.
- 6 · RetiradaPlanejar continuidade, dados e encerramento.
| Etapa | Evidência útil para decidir | Responsabilidade a combinar |
|---|---|---|
| Necessidade | Problema, usuários, situação atual e resultado esperado | Área solicitante e gestor do produto |
| Desenvolvimento e avaliação | Requisitos, riscos e evidências de verificação/validação aplicáveis | Fabricante ou desenvolvedor; interlocutores da instituição |
| Implantação | Aceite, integrações, treinamento, suporte e pendências | Líder da implantação e áreas que recebem a operação |
| Uso e acompanhamento | Ocorrências, uso efetivo, suporte, disponibilidade e resultado observado | Gestor do produto e responsáveis locais |
| Mudança | Versões afetadas, dependências, impacto e registros de execução | Fabricante/desenvolvedor, TI, engenharia clínica e usuários envolvidos |
| Retirada | Alternativa operacional, destinação, dados e encerramento do suporte | Gestor responsável, TI, engenharia clínica e áreas aplicáveis |
O fabricante e a instituição têm papéis distintos. A organização que desenvolve o dispositivo precisa tratar requisitos e evidências do produto. O serviço de saúde precisa conhecer sua configuração em uso, receber orientações pertinentes, registrar ocorrências e organizar intervenções. Um painel de manutenção ajuda a operação; a avaliação de segurança e desempenho exige as evidências correspondentes ao produto e à finalidade de uso.
Por que controlar versões e integrações depois da implantação?
Um caso documentado pela FDA sobre BD Alaris mostra a importância desse acompanhamento. A comunicação de correção enviada em 18 de fevereiro de 2025 envolvia Systems Manager e CCE Infusion Adapter 1.7.2. Atrasos podiam acumular solicitações de programação e apresentar parâmetros desatualizados à bomba; sua aceitação poderia resultar em terapia incorreta.
A ação incluía atualizar o adaptador para 1.7.3, com suporte do fabricante, e tratar software duplicado. O aviso informava ausência de lesões e mortes relatadas até então. Trata-se de um caso dos Estados Unidos, com condições e instruções específicas; não fornece uma frequência de falhas nem um procedimento para outras bombas.
A consequência para a gestão é concreta: uma lista de nomes de softwares não descreve a configuração em operação. O registro deve permitir identificar versão, dependências, locais afetados, orientação recebida e comprovação da intervenção. Uma atualização que muda a integração precisa ser acompanhada pelas áreas que conhecem o fluxo assistencial e pelo responsável técnico pertinente.
Quais normas e regras se relacionam ao tema?
As referências cumprem funções diferentes. A tabela orienta a escolha inicial; o enquadramento depende do produto e de sua finalidade.
| Referência consultada | Escopo relevante | Limite importante |
|---|---|---|
| ISO 13485:2016 | Sistema de gestão da qualidade de organizações que atuam com dispositivos médicos | Não equivale à acreditação de um hospital ou à demonstração isolada de desempenho de um produto |
| IEC 62304:2006 + AMD1:2015 | Desenvolvimento e manutenção de software de dispositivo médico, inclusive embarcado | O catálogo explicita que não cobre a validação e a liberação final do dispositivo médico |
| RDC 657/2022 — Anvisa | Regularização de software como dispositivo médico no Brasil | Não se aplica a todo software usado em um hospital |
Na RDC 657, os arts. 7 e 8 tratam de atualização, interoperabilidade, compatibilidade e identificação de produto/versão. O art. 16 diferencia alterações sujeitas a peticionamento de manutenções simples que preservem as condições especificadas. Portanto, o impacto da mudança precisa ser avaliado antes de classificá-la como uma simples correção.
Há uma distinção de escopo útil: a IEC 62304 abrange software embarcado. A RDC 657 o exclui de seu escopo específico, mas seu art. 3 determina a regularização conjunta com o dispositivo associado. Software exclusivamente administrativo e financeiro também está excluído dessa resolução; a finalidade é decisiva.
Os escopos IEC/ISO foram conferidos nos catálogos públicos, sem acesso ao texto integral pago. A RDC 657 constava como Vigente na consulta ao AnvisaLegis em 6 de outubro de 2026. Não se atribui certificação ou regularização a um produto pela mera menção dessas referências.
Como medir se o produto continua útil?
Escolha indicadores que respondam à necessidade original e defina a unidade de observação. Uso ativo, ocorrência, chamado e equipamento são unidades diferentes. Uma ocorrência pode gerar vários chamados; somá-los como se fossem problemas independentes distorce a análise.
| Pergunta de gestão | Medida possível | Definição que precisa acompanhar o número |
|---|---|---|
| As pessoas conseguem executar a tarefa? | Tarefas concluídas entre tentativas observadas | Tarefa, perfil do usuário, versão, período e critério de conclusão |
| A solução está sendo usada? | Usuários ou setores ativos entre os habilitados | O que conta como atividade, janela temporal e população elegível |
| O suporte resolve a dificuldade? | Tempo até resolução e problemas recorrentes | Marco inicial/final, reaberturas e ocorrências ainda pendentes |
| Uma mudança trouxe o efeito esperado? | Resultado observado antes/depois da mudança | Contexto, exposição, alteração de equipe ou demanda e limites da comparação |
Essas medidas são propostas editoriais, não metas universais. Acompanhe também o trabalho que mudou de lugar: tempo economizado em uma área pode virar conferência, cadastro ou suporte em outra. Registrar esse esforço ajuda a decidir se o produto deve ser ampliado, ajustado ou substituído.
Quando a necessidade é acompanhar intervenções e histórico de ativos, o CMMS Arkmeds oferece planejamento de manutenção e calibração, ordens de serviço, relatórios e consulta do histórico por web ou QR Code, conforme a documentação comercial. Esses registros ajudam a ligar o ativo ao trabalho realizado; a documentação de desenvolvimento e validação deve permanecer sob a responsabilidade correspondente.
Precisa organizar o histórico técnico dos ativos em operação?
O que registrar em uma mudança ou retirada?
Use os campos abaixo como pauta de reunião ou registro de decisão. Ajuste-os ao produto, às responsabilidades internas e às instruções aplicáveis.
- Identificação: produto, versão, ativos ou setores afetados e responsável pelo registro.
- Motivo: necessidade, ocorrência, orientação do fabricante ou fim de suporte que desencadeou a avaliação.
- Impacto: usuários, integrações, continuidade, segurança, dados e evidências que precisam ser revistas.
- Decisão: manter, ajustar, atualizar, ampliar ou retirar, com justificativa e responsáveis.
- Execução: orientação utilizada, verificações aplicáveis, treinamento e comprovação do que foi realizado.
- Continuidade: alternativa operacional e destino dos dados/registros quando o produto for retirado.
- Acompanhamento: pendências, critério de conclusão e data da próxima revisão.
Na retirada, confirme quais equipamentos, contratos, integrações e acessos dependem da solução. Preserve a possibilidade de recuperar os registros necessários segundo a política e os requisitos aplicáveis ao serviço. Encerrar o contrato sem planejar essa transição pode deixar a equipe com um histórico que já não consegue consultar.
Esse registro reúne a decisão e suas evidências em um lugar recuperável. Na próxima reunião, permite verificar o que foi executado, o que mudou no uso e quem responde pelas pendências.
Fontes e leituras
- Greenhalgh et al. (2017) — NASSS, artigo original
- FDA — correção do software BD Alaris/CCE (2025)
- Anvisa — RDC 657/2022, texto com retificação
- ISO — catálogo ISO 13485:2016
- IEC — catálogo IEC 62304:2006+AMD1:2015 CSV
- Arkmeds — documentação comercial do CMMS
Pesquisa e revisão: 6 de outubro de 2026. Publicação original: 26 de agosto de 2025. Infográfico próprio de contagens publicadas; mapa e propostas de registro editoriais. Estudos e caso de correção não avaliaram produtos Arkmeds.
