Software para home care: guia de compra e demonstração

Para escolher um software para home care, compare o trabalho que sua equipe conseguirá executar, as evidências que a gestão poderá conferir e as responsabilidades que continuarão com a empresa. A lista de funcionalidades é apenas o começo. O processo de compra precisa chegar à demonstração, ao escopo contratado e ao aceite da implantação.

Uma apresentação pode mostrar uma agenda organizada e um painel convincente. Isso ainda não responde o que acontece quando o profissional é substituído, o plano muda depois da programação ou a visita foi realizada, mas o registro não chegou. É nessas situações que coordenação, assistência e faturamento deixam de conseguir trabalhar apenas com uma lista de tarefas.

Este guia propõe um método de avaliação para diretores, coordenadores assistenciais e responsáveis por operação, tecnologia e administração de empresas de home care. Os cenários são fictícios e devem ser adaptados ao serviço. Não são testes já realizados de fornecedores nem uma lista de funcionalidades da HAI. Se você compra ou supervisiona uma rede pela fonte pagadora, consulte o roteiro específico de avaliação para operadoras.

A pergunta de compra é simples: sua equipe consegue executar e conferir o fluxo, inclusive quando algo sai do previsto? A resposta precisa sobreviver ao fim da apresentação comercial.

1. Defina qual operação o sistema precisa sustentar

“Home care” reúne operações diferentes. Uma empresa que organiza visitas de várias especialidades, outra que trabalha com plantões e uma terceira que combina equipes próprias e prestadores não terão a mesma prioridade. O número de pacientes, sozinho, não descreve essa complexidade.

Antes de convidar fornecedores, produza uma página com cinco informações:

• Serviço e público: quais modalidades de atendimento e linhas de cuidado fazem parte da operação, definidos pelos responsáveis assistenciais.
• Trabalho em campo: visitas, plantões, especialidades, locais atendidos e condições de conexão relevantes.
• Quem participa: coordenação, profissionais, prestadores, família, auditoria e fonte pagadora, quando aplicável.
• Processo atual: onde nascem pedido, plano, agenda, registro e informação usada no fechamento.
• Problema prioritário: qual falha precisa ser corrigida e qual evidência mostrará que o processo mudou.

Exemplo fictício: “não sabemos a situação das visitas” é amplo demais. Uma formulação mais útil é: “a coordenação não distingue visita não realizada de visita realizada com registro pendente; precisa identificar cada situação e encaminhar a apuração”. Essa diferença muda a demonstração, o treinamento e a responsabilidade pelo dado.

O DIIG da Organização Mundial da Saúde orienta o planejamento de saúde digital a partir das necessidades, da capacidade de implementação e dos investimentos necessários. O guia tem contexto de programas de saúde; aqui usamos essa lógica de planejamento, sem apresentá-lo como certificação de fornecedores ou roteiro obrigatório de compra.

2. Separe requisitos obrigatórios de preferências

Uma avaliação perde força quando todo pedido vira “indispensável”. Ela também falha quando uma boa aparência compensa uma condição que a operação não pode aceitar. Requisito obrigatório precisa ter motivo, responsável e forma de verificação.

Evite transformar essa tabela em um ranking de números arbitrários. Se usar pesos, combine-os antes das demonstrações e registre a justificativa. Uma condição de acesso ou continuidade que seja obrigatória não deve desaparecer dentro de uma média alta de recursos secundários.

Também diferencie o sistema assistencial do conjunto de ferramentas da empresa. Ver prontuário, agenda e orçamento na mesma apresentação não prova que folha, contabilidade, compras, estoque e todos os processos de cobrança estejam incluídos. A fronteira de cada proposta precisa ficar explícita.

3. Use o mesmo caso nas demonstrações

Prepare um caso fictício com um plano, atividades programadas, profissionais com perfis diferentes e uma regra administrativa de conferência. Mantenha o caso igual entre fornecedores. Deixe a solução mostrar seu próprio fluxo, mas peça o mesmo resultado verificável.

Não leve dados reais de pacientes para uma apresentação comercial. A avaliação deve revelar o funcionamento sem depender de exposição de informação sensível.

Cenário 1: o plano muda depois de a agenda ser criada

Peça para demonstrar: criar o plano, programar atividades e alterar uma frequência ou um profissional com autorização do papel adequado.

Confira: o que acontece com a programação futura, como a equipe distingue a versão atual da anterior e como identifica as atividades já realizadas. Quem recebe a informação da mudança? O profissional consegue consultar o que vale para a próxima visita?

Sinal de pendência: a mudança só é explicada verbalmente ou exige redigitar informações em vários lugares sem uma conferência definida. O problema não é a existência de uma etapa manual, e sim ela ficar invisível na comparação.

Cenário 2: uma atividade fica sem cobertura

Peça para demonstrar: retirar a disponibilidade do profissional inicialmente previsto e acompanhar a tratativa pela coordenação.

Confira: como a atividade é encontrada, quem assume a pendência e como a substituição chega ao novo profissional. Se o modelo envolve prestadores, verifique quais passos cabem a cada organização e quais módulos sustentam esse processo.

Sinal de pendência: a apresentação termina no alerta. Um alerta sem responsável e sem condição de encerramento pode apenas transferir para outra tela o problema que já existia nas mensagens.

Cenário 3: a visita ocorreu, mas a informação ainda não chegou

Peça para demonstrar: um registro recebido depois do horário esperado e, quando necessário para a operação, perda de conexão e posterior sincronização.

Confira: a distinção entre horário da atividade, horário do registro e recebimento pelo sistema, conforme os recursos disponíveis. Observe também o tratamento de duplicidade e as tarefas que de fato funcionam sem conexão. “Tem aplicativo” não responde essas perguntas.

Sinal de pendência: o painel trata ausência de informação como certeza de não atendimento. O roteiro de teste do aplicativo sem internet detalha a verificação, sem presumir que qualquer versão ofereça todos os comportamentos.

Cenário 4: o registro precisa de uma correção

Peça para demonstrar: encontrar um preenchimento incompleto, encaminhar a correção e conferir a versão ajustada.

Confira: quem pode corrigir, o que permanece no histórico, como a pendência é reavaliada e qual informação fica disponível para quem confere o fechamento. A avaliação precisa envolver o profissional que registra e quem usa esse registro depois.

Sinal de pendência: qualquer pessoa altera o dado sem explicação do histórico, ou a correção só é possível por uma intervenção cujo processo não está descrito. Leve as condições de registro e guarda às áreas responsáveis, em vez de resolver a dúvida por suposição.

Cenário 5: o realizado diverge do previsto na conferência

Peça para demonstrar: comparar atividades planejadas e registradas, incluindo alteração, ausência e documentação pendente.

Confira: se é possível chegar à evidência de uma linha da conferência e explicar por que ela entrou naquela situação. Identifique a fronteira entre registro assistencial, conferência administrativa, regra contratual e processamento da cobrança.

Sinal de pendência: visita registrada é tratada como receita recebida. São etapas diferentes. Um sistema pode apoiar a documentação sem cobrir todo o ciclo financeiro; isso precisa estar claro no escopo. Para aprofundar, leia glosa na atenção domiciliar e o papel do registro.

Cenário 6: um profissional muda de vínculo ou deixa a operação

Peça para demonstrar: revisar permissões, retirar acesso e preservar a consulta aos registros anteriores pelos perfis autorizados.

Confira: quem aprova a mudança, como ficam os vínculos entre organizações e qual evidência da ação pode ser consultada. Não confunda acesso ao aplicativo com autorização para consultar todos os pacientes ou todas as unidades.

Sinal de pendência: a separação de acesso depende apenas de um acordo informal. A análise de segurança e privacidade precisa conferir documentação, contrato e funcionamento, com participação das áreas responsáveis. Há um roteiro complementar de segurança e privacidade.

Cenário 7: a empresa precisa recuperar suas informações

Peça para demonstrar: exportar um conjunto fictício e explicar quais dados, documentos, vínculos e históricos estão contemplados.

Confira: o que o arquivo permite consultar e o que exigiria trabalho para importar em outro sistema. Defina também o funcionamento de contingência e a reconciliação do trabalho registrado durante uma indisponibilidade.

Sinal de pendência: “os dados são seus” aparece como resposta completa, sem formato, conteúdo, responsabilidades ou condições de entrega. Nosso guia de migração de sistema no home care aprofunda esse percurso. A referência do NHS England sobre conferência de dados reforça comparar dados, registrar problemas e conferir as correções antes do aceite. É uma referência internacional, não regra contratual brasileira.

4. Registre o que foi provado, não apenas o que foi dito

Ao terminar cada cenário, classifique a resposta. Use linguagem que o comitê consiga conferir depois:

Uma promessa de roadmap não equivale a uma função disponível. E uma função disponível não prova que a sua equipe conseguirá usá-la com os seus cadastros, dispositivos e responsabilidades. As duas verificações são necessárias.

Na ata, registre requisito, cenário, resultado, evidência, pendência, responsável e condição de encerramento. Não é preciso um relatório extenso para cada clique. É preciso preservar o suficiente para que a decisão não dependa da memória de quem assistiu à reunião.

Baixe a matriz de avaliação em CSV e abra no seu editor de planilhas. Ela contém os sete cenários e campos para registrar evidências e pendências. Preencha somente dados da avaliação, sem informações de pacientes. É um modelo de trabalho, não uma pontuação validada de fornecedores.

5. Compare o custo do mesmo escopo

A mensalidade não descreve todo o esforço para colocar um sistema em uso. Compare propostas com a mesma população, os mesmos módulos e as mesmas condições de implantação. Separe valores confirmados, estimativas internas e dependências ainda sem orçamento.

Organize a análise em quatro grupos:

1. Uso recorrente: unidade de cobrança, módulos, perfis, suporte e condições de expansão previstos na proposta.
2. Entrada em operação: preparação de cadastros, configuração, migração, treinamento, homologação e dedicação dos usuários de referência.
3. Convivência e sustentação: integrações, conciliação temporária entre sistemas, manutenção das regras e atualização da documentação.
4. Mudança ou encerramento: exportação, transição, dependências e esforço para manter a continuidade.

Não some valores de períodos diferentes. Não transforme horas liberadas em economia financeira automática: a equipe pode usar esse tempo para atender demanda reprimida, conferir melhor ou ampliar a capacidade, sem redução equivalente da despesa. Explicite qual efeito está sendo avaliado.

O artigo sobre custos de implantação além do software ajuda a organizar essa análise. A comparação deve revelar custo e dependência, não produzir uma justificativa financeira depois de a decisão já ter sido tomada.

6. A liderança também precisa passar pelo teste

Escolher o sistema é uma responsabilidade compartilhada, mas não anônima. Direção define prioridade e disponibilidade; coordenação valida o processo; campo testa o uso; administração confere o fechamento; tecnologia e segurança avaliam dados, acessos e dependências.

Não ler a proposta, não participar dos testes e transferir toda dúvida para o fornecedor são comportamentos incompatíveis com a responsabilidade de aprovar a compra. Um gestor não precisa dominar cada configuração. Precisa compreender o processo que está autorizando e reservar pessoas capazes de validá-lo.

O fornecedor, por sua vez, deve responder com clareza sobre recursos, limites, dependências e escopo. “É só treinar” não encerra uma dificuldade sem investigar se o fluxo funciona, se os acessos estão corretos e se a orientação foi suficiente. A preparação da adesão da rede faz parte da implantação, não é um problema a descobrir depois da assinatura.

Pedidos de novas funcionalidades também precisam de critério. Se a equipe não compreendeu um processo, não recebeu orientação ou trabalha com documentos desatualizados, uma nova função pode acrescentar complexidade sem tratar a causa. Pedir desenvolvimento não substitui comunicar com os usuários e manter a documentação do projeto atualizada.

7. Termine com um aceite que possa ser conferido

Defina o primeiro escopo, os responsáveis e as condições para ampliar. Os critérios precisam existir antes do teste e refletir as condições de entrada escolhidas. Evite aprovar a implantação apenas porque houve treinamento ou porque usuários entraram no sistema.

Exemplo fictício de critério: a coordenação consegue localizar uma atividade pendente, distinguir a causa conhecida de uma informação ainda em apuração, encaminhar a tratativa e conferir seu encerramento. O profissional responsável consegue executar sua parte com o perfil previsto. O responsável administrativo encontra a evidência necessária ao seu processo, dentro do escopo contratado.

Uma pendência impeditiva precisa estar resolvida ou levar à revisão explícita da decisão. As demais podem ser acompanhadas com impacto, responsável e condição de encerramento conhecidos. O caminho também pode ser não contratar. Uma avaliação útil protege a operação de uma escolha inadequada, inclusive quando isso encerra a negociação.

As orientações SAFER da ONC tratam de configuração, validação e uso seguro de tecnologia em saúde. Elas apoiam a atenção aos processos e às dependências; não certificam a HAI nem substituem a avaliação local.

Como avaliar a HAI com esse roteiro

A HAI, software da Salvus para home care e atenção domiciliar, conecta PAD, agenda, profissionais, registros de visitas, pendências e indicadores. A demonstração deve esclarecer o que a plataforma atende no seu fluxo e o que depende de versão do aplicativo, módulos, configuração ou integração a homologar.

Somos o fornecedor da HAI, portanto este guia não é um ranking independente de soluções. A proposta é oferecer critérios que você possa usar também em outras avaliações. A HAI deve ser submetida às mesmas perguntas.

Leve para a conversa o problema prioritário, os sistemas existentes e dois cenários que sua equipe precisa conferir. Agende uma demonstração da HAI, com dados fictícios e uma lista explícita de evidências e pendências. Depois, use o kit para o comitê para organizar a decisão.

Fontes e método

Este é um roteiro editorial de avaliação, composto a partir dos problemas de coordenação, adoção e conferência tratados no acervo da Salvus. A matriz e os cenários são propostas de trabalho, não um instrumento validado, aconselhamento clínico ou resultado medido de clientes.

• OMS: Digital Implementation Investment Guide, 2020. Planejamento de investimentos orientado por necessidades e capacidade de implementação.
• ONC: Implementing Health IT / SAFER. Referência internacional de configuração e validação de tecnologia em saúde.
• NHS England: Data checking. Conferência de dados e correções em migração de sistemas.

As condições comerciais, técnicas e de tratamento de dados precisam ser avaliadas na documentação vigente de cada proposta. Não presumimos equivalência entre fornecedores nem disponibilidade de um recurso que não tenha sido demonstrado e confirmado no escopo.