Do discovery ao MVP em saúde: guia prático para CTOs

O enquadramento regulatório depende do que o software faz, dos dados processados e do impacto da saída na assistência. Um sistema administrativo de agendamento não tem o mesmo perfil de risco de uma solução que interpreta imagens, sugere diagnóstico ou calcula dose de medicamento. O CTO deve documentar essa fronteira durante o discovery, sem presumir que todo MVP de saúde seja apenas um sistema de informação.

A Lei Geral de Proteção de Dados Pessoais, conforme a ANPD trata dados referentes à saúde como dados pessoais sensíveis. Na prática, isso exige definir finalidade, base legal, minimização, controle de acesso, retenção, descarte e atendimento aos direitos dos titulares. Consentimento não é uma solução automática para qualquer cenário, especialmente quando há vínculo assistencial ou institucional.

Se o software puder ser caracterizado como dispositivo médico, a avaliação precisa envolver a regulamentação aplicável da Anvisa. A orientação oficial da Anvisa sobre software como dispositivo médico é um ponto de partida para entender quando a finalidade pretendida e as funções do sistema podem exigir regularização específica.

Projetos que envolvem pesquisa com seres humanos devem ser analisados também sob a ótica ética. O Conselho Nacional de Saúde, na Resolução nº 466, estabelece diretrizes para pesquisas envolvendo participantes. Um teste de usabilidade de uma interface administrativa pode ter tratamento diferente de um estudo que coleta dados clínicos ou mede desfechos, portanto o protocolo deve ser avaliado por profissionais jurídicos, de privacidade e ética em pesquisa quando aplicável.

O checklist regulatório mínimo deve responder cinco perguntas: qual é a finalidade do produto, qual é o risco clínico, quem é o controlador dos dados, quais terceiros terão acesso e qual evidência sustenta o uso. Se uma resposta ainda for vaga, o MVP não está pronto para um piloto com dados reais. Use dados sintéticos ou desidentificados enquanto a governança não estiver definida.

Um piloto hospitalar não deve começar com apenas um protótipo funcionando. A instituição precisa entender finalidade, responsabilidades, fluxo de dados, suporte, limites de uso e plano de resposta a incidentes. Sem esses elementos, o projeto pode ser interrompido pelo jurídico ou pela segurança da informação mesmo que os usuários aprovem a experiência.

No conjunto jurídico, prepare um acordo de tratamento de dados, definição de papéis entre controlador e operador, regras de confidencialidade, propriedade intelectual, subcontratação e encerramento do acesso. O documento deve indicar o que ocorre com cópias, registros, backups e credenciais quando o piloto terminar.

No conjunto de produto, mantenha mapa da jornada clínica, matriz de riscos, finalidade pretendida, critérios de inclusão e exclusão, roteiro de treinamento e registro de feedback. O material deve permitir que um profissional que não participou do discovery entenda o fluxo e identifique onde o sistema pode falhar.

No conjunto técnico, tenha diagrama de arquitetura, inventário de dados, matriz de permissões, política de retenção, trilha de auditoria, estratégia de backup e plano de restauração. Para integrações, registre contratos de API, limites de consumo, tratamento de indisponibilidade e comportamento quando uma informação estiver desatualizada.

Também prepare um pacote de evidências. Ele pode conter resultados dos testes de usabilidade, casos de teste, análise de vulnerabilidades, decisões de arquitetura, atas de aprovação e lista de pendências. Em projetos apoiados por FAPESC, FINEP ou BNDES, essa organização facilita a demonstração de entregáveis e reduz o risco de confundir protótipo, prova de conceito e produto operacional.

A escolha entre cloud pública e arquitetura híbrida não deve ser feita por preferência de fornecedor. O critério é o conjunto de dados, integrações, latência, exigências contratuais e capacidade operacional da organização. AWS, Microsoft Azure e Google Cloud oferecem recursos robustos, mas nenhum serviço elimina a responsabilidade do cliente sobre configuração, identidade, classificação e uso dos dados.

A cloud pública tende a acelerar o MVP quando a equipe precisa provisionar ambientes, aplicar políticas de identidade, automatizar cópias e escalar componentes sem comprar infraestrutura. Ela funciona melhor quando a instituição aceita o modelo de responsabilidade compartilhada e possui uma arquitetura clara para separar dados sensíveis, telemetria e informações de teste.

A arquitetura híbrida pode fazer sentido quando o hospital precisa manter o prontuário ou determinados sistemas dentro da rede institucional. Nesse caso, o MVP pode operar na nuvem com dados minimizados, enquanto um conector local consulta apenas o necessário por APIs autenticadas. O desenho deve prever filas, cache controlado, indisponibilidade e sincronização, não apenas um túnel de rede.

Para decidir, monte uma matriz com seis dimensões: localização e jurisdição dos dados, integração com sistemas legados, latência, disponibilidade, custo operacional e capacidade do time interno. Uma solução híbrida pode reduzir uma preocupação contratual e aumentar a complexidade de suporte. Uma solução totalmente pública pode simplificar a operação e exigir mais trabalho de negociação com o cliente.

No MVP, evite distribuir componentes por múltiplas nuvens sem uma razão concreta. O uso de AWS, Azure ou GCP deve ser acompanhado de criptografia, gerenciamento de segredos, registros de auditoria, segregação por ambiente e testes de restauração. O guia sobre como escolher a nuvem para MVPs regulados pode apoiar essa avaliação, mas a decisão final precisa considerar o contrato e a operação do parceiro de saúde.

Uma execução disciplinada pode ser dividida em quatro ciclos. No primeiro, o time entende a demanda, entrevista usuários e decisores, mapeia dados e registra riscos. No segundo, testa a jornada com protótipos de baixa fidelidade e dados seguros. No terceiro, constrói o menor fluxo funcional com controles de segurança incorporados. No quarto, conduz o piloto com métricas, suporte e decisão formal de continuidade.

A equipe também deve definir o que não será construído. Integrações não essenciais, automação completa de exceções e modelos sofisticados podem esperar enquanto a hipótese principal não foi comprovada. Um MVP de triagem talvez precise apenas organizar informações e permitir revisão humana, em vez de automatizar a decisão clínica inteira.

A OrbeSoft aplica essa lógica em projetos sob medida, combinando discovery, UX/UI, engenharia e inteligência artificial quando ela é realmente necessária. A empresa trabalha com squads seniores dedicadas, o que permite discutir o escopo, a arquitetura e os riscos com o cliente em vez de simplesmente transformar qualquer pedido em backlog.

Essa postura é especialmente útil quando CEO e CTO enxergam prioridades diferentes. O negócio busca velocidade para testar uma oportunidade, enquanto a tecnologia precisa preservar segurança, sustentabilidade e capacidade de operação. A discussão pode ser estruturada com critérios de evidência, risco e custo de atraso, como no playbook para contratar squad sênior dedicada ou ampliar o time interno.

Em projetos de saúde, a entrega final não deve ser medida pela quantidade de telas ou solicitações concluídas. Os sinais mais úteis são uma hipótese clínica claramente delimitada, uma jornada compreendida pelos usuários, dados tratados com controle, incidentes respondidos rapidamente e uma decisão baseada em evidências sobre o próximo investimento. Essa é a diferença entre lançar um protótipo e preparar um produto responsável.