A noite depois da visita ao consultório foi uma dessas noites em que, na verdade, você não quer fazer mais nada. Eu estava em casa, com um caderno na frente no qual, pela manhã, tinha ido anotando risquinhos. Quantas vezes Mala procurou uma ficha? Quantas vezes copiou o mesmo número de telefone? Quantas vezes a médica precisou escrever duas vezes uma frase da receita porque o primeiro papel não dava para ler na farmácia?
Sou cuidadoso com números que não medi direito, e esses eu não medi direito. Foram três horas de observação, um lápis e a minha intuição. Mas a intuição era clara. Ao longo do dia, naquele consultório pequeno, várias horas se perdiam em tarefas que um computador resolve em segundos: procurar, copiar, conferir, reescrever. Várias horas, todo dia, pagas a alguém que na verdade está ali para outra coisa.
Por que não simplesmente comprar algo
Foi minha primeira reação, e é a certa. Em vinte anos aprendi que construir software próprio é quase sempre a resposta mais cara para um problema. Então fui ver o que existia. O mundo dos softwares para consultório se divide, grosso modo, em três tipos, pelo menos como vivi na época.
O primeiro tipo é grande demais. São sistemas para clínicas com departamento de TI, com treinamentos e projetos de implantação de meses. Para três médicos e uma recepcionista, é como comprar um caminhão para ir buscar pão.
O segundo tipo é velho demais. Programas que um dia foram bons, mas cuja tela parece que ninguém toca há quinze anos, e sobre os quais a gente se pergunta quem ainda os mantém.
O terceiro tipo é bom, mas de outro mundo. Os produtos modernos na nuvem costumam ser excelentes, mas são feitos para um mercado que não é o desse consultório: outra moeda, outros formatos de imposto, outra internet. Contei isso em detalhes na minha comparação com o Cliniko, então não quero repetir aqui. Só digo que não descartei esses produtos por serem ruins. Descartei porque foram feitos para outras salas.
A regra que me dei
Antes de escrever a primeira linha de código, anotei uma regra: só construo o que naquele consultório se usa todo dia. Nada que só fique bonito. Nada que eu construa só porque sei fazer.
Parece óbvio. Na verdade é a disciplina mais difícil que conheço, porque, como desenvolvedor, a gente tem ideias o tempo todo. Um painel com gráficos bonitos. Uma função de lembretes. Uma estatística. Coloquei todas essas ideias numa lista que chamei de “depois” e não mexi nela até o básico funcionar.
O básico eram, segundo meus risquinhos, cinco coisas.
O que construí primeiro
O paciente. Um formulário com o que Mala já pergunta por telefone de qualquer jeito: nome, data de nascimento, sexo, telefone, endereço. E coisas que uma médica quer saber antes de receitar: tipo sanguíneo, alergias, histórico. Fiquei um bom tempo em dúvida se alergias deviam ser um campo próprio ou parte do histórico. Decidi por um campo próprio, porque não queria que se perdessem no meio de vinte linhas de texto.
A consulta marcada. Uma consulta marcada pertence a um paciente e a um médico, tem data, hora, um tipo (por exemplo consulta ou retorno) e um status. Na tela inicial está a lista das consultas do dia. Parece banal, mas é exatamente essa lista que Mala copiava toda manhã da agenda.
O atendimento. É o núcleo. A médica anota o que a paciente tem, queixas e sintomas, o diagnóstico, o que receita, se recomenda exames e quando a paciente deve voltar. Tudo fica ligado à consulta marcada e à paciente.
O laboratório. Um pedido de exame, um status, um resultado. Nada mais. Mas substitui a pilha de fotos que chegavam no aplicativo de mensagens do consultório.
A cobrança. Uma cobrança tem itens de consulta, medicamentos, laboratório e outros, um desconto, um total, o valor pago, a forma de pagamento e um status. Soma-se uma lista simples de farmácia com estoque, mínimo e data de validade, porque o consultório dispensa alguns medicamentos por conta própria.
É isso. Nenhum milagre, mas é o que realmente acontece num dia normal.
Por que um programa de desktop
A pergunta que todo desenvolvedor me faz: por que não um aplicativo web? Seria hoje o caminho natural. A resposta tem a ver com o consultório, não comigo.
Um aplicativo web precisa de um servidor e de conexão com a internet. Quem opera o servidor precisa mantê-lo, fazer backup, atualizar. Um consultório pequeno não tem ninguém para isso. Quem o aluga entrega os dados dos pacientes, e justamente isso a médica não queria. E quando a internet cai, tudo para.
Então construí um programa de Windows que funciona sem internet. Os dados ficam num único arquivo SQLite no computador do consultório. Por dentro é VB.NET, e a tela é uma visualização web dentro da janela do Windows, porque assim consigo mais rápido um visual limpo. Para o consultório, só significa: abrir o programa, trabalhar, copiar o arquivo.
Isso tem um preço, e não quero escondê-lo. Um programa local significa que o consultório é responsável pelos próprios backups. Vários computadores usando os mesmos dados ao mesmo tempo é mais difícil do que numa solução em nuvem. E alguém precisa instalar as atualizações. Pesei essas desvantagens contra a vantagem de o consultório poder continuar trabalhando mesmo quando a luz pisca e a rede some, e fiquei com o programa de desktop. Para outro consultório, a conta pode dar diferente.
O que me surpreendeu
Achei que os maiores desafios seriam técnicos. Mal foram. As maiores surpresas vieram de Mala e da médica.
Mala queria que, ao criar uma consulta, aparecesse na hora se a paciente já tinha vindo antes. Eu não tinha previsto. Era um pedido pequeno, mas me mostrou no que repara quem trabalha com o telefone preso entre o ombro e a orelha. Coloquei na lista.
A médica queria marcar a data do próximo retorno direto no atendimento, não numa janela de agendamento separada. Ela disse: “Se eu escrevo onde já escrevo de qualquer jeito, não esqueço.” Por isso há um campo para isso no atendimento.
O que mais me impressionou: quase nunca me disseram o que gostavam. Disseram-me o que atrapalhava. É o melhor retorno que se pode receber, e aprendi a prestar atenção em suspiros, não em elogios.
As semanas em que duvidei
Houve uma fase, mais ou menos depois do primeiro mês, em que pensei a sério em jogar tudo fora. Não porque tecnicamente não desse, mas porque me fiz a mais honesta das perguntas: quem realmente precisa de mais um software para consultório?
Existem dezenas. Alguns são muito bons. Durante duas semanas tive a sensação de estar reinventando uma roda que já é perfeitamente redonda. À noite, sentava com as linhas de código na frente e pensava: você poderia ter indicado uma assinatura para a médica e o assunto estaria resolvido.
O que no fim me manteve não foi uma grande meta, mas uma observação pequena e nada romântica. Toda vez que eu passava no consultório, a agenda ainda estava sobre a mesa, mas Mala olhava cada vez mais vezes primeiro para a tela. Não porque eu a empurrasse, mas porque a lista de lá era mais rápida. É uma frase que guardei: ninguém muda por um bom argumento, as pessoas mudam porque algo é mais fácil.
O que escolhi não construir
Uma lista do que não está diz mais sobre um produto do que uma lista do que está. Esta é a minha.
Não incluí inteligência artificial que sugira diagnósticos. Pedem isso com frequência, e acho uma má ideia num programa que um único desenvolvedor constrói e não consegue validar clinicamente. Um erro ali não seria um defeito estético.
Não incluí uma base de medicamentos com verificação de interações. O texto da receita no atendimento é um campo de texto. A médica escreve o que receita. O programa não pensa junto, e não quero apresentá-lo de outro modo. Uma base de medicamentos revisada é um projeto de vários anos com especialistas, não algo que se acrescenta de passagem.
Não construí contas de usuário com papéis e permissões no sentido dos sistemas grandes. Para três médicos e uma recepcionista que se conhecem, não era o problema mais urgente. Para um consultório maior seria, e então eu precisaria correr atrás.
E não construí conexão com convênios e seguradoras. Naquele consultório a maioria dos pacientes paga do próprio bolso, e cada conexão seria um país diferente com regras próprias.
Uma manhã com o programa
Imagine que são oito e meia. Mala liga o computador e abre o programa. Na tela inicial estão as consultas do dia, ordenadas por hora. A primeira é um retorno, a segunda um paciente novo.
O paciente novo entra. Mala o cadastra: nome, data de nascimento, telefone, uma frase sobre alergias que ele cita quando perguntam. Leva um minuto. A médica abre a consulta, anota as queixas, escreve o diagnóstico, digita a receita e marca a data do retorno. Se quiser um exame de sangue, cria um pedido de laboratório.
No fim o paciente volta a sentar com Mala. Ela emite a cobrança: consulta, medicamentos, laboratório, talvez um desconto, pagamento em dinheiro ou de outra forma. Pronto.
Nada disso é espetacular, e esse é o ponto. Como desenvolvedor, às vezes a gente gostaria que alguém dissesse “uau”. Aqui seria mau sinal. Quando o software é bom, ninguém diz nada. Ele simplesmente está lá, e a manhã passa mais rápido.
O que tudo isso me custou
Quero ser honesto sobre tempo e esforço, porque acho que muitos desenvolvedores enfeitam isso.
Um programa como este não é coisa de uns fins de semana. A primeira versão que se pode mostrar fica pronta em poucos dias. A versão em que alguém se apoia no dia a dia leva meses, e exige sobretudo a paciência de voltar sempre ao consultório, observar e jogar fora coisas que a gente achava inteligentes. Passei mais tempo observando do que programando, e faria de novo.
Além disso, há responsabilidade. Quando um consultório confia suas consultas e seus prontuários a um programa, um erro ali deixa de ser brincadeira. Por isso aprendi a ser cauteloso com promessas, e peguei o costume de dizer, em cada texto como este, o que não funciona.
Há ainda uma coisa de que quase ninguém fala: a solidão desse tipo de projeto. Quando você constrói sozinho, não há ninguém para dizer que uma ideia é ruim antes de você gastar uma semana nela. Aprendi a substituir isso por uma regra simples: antes de construir qualquer coisa nova, eu a descrevo em três frases a Mala ou à médica. Se elas não entendem para que serve, não construo.
O que ainda falta, e por que não escondo
O ClinicPlusPlus não está pronto. Não escrevo isso por modéstia, mas porque é verdade.
Algumas telas ainda são protótipos. O início e os relatórios ainda não estão ligados em todo lugar aos dados reais. Não há backup automático, só copiar o arquivo à mão. Uma cobrança conforme a regra tributária da Índia, com GST, está na minha lista e ainda não foi construída. Os pacientes não podem agendar online e não há lembretes por SMS. Também ainda não existe proteção automática contra consultas marcadas em duplicidade; vou escrever sobre isso num texto à parte.
Quem precisa de uma solução pronta não deve esperar pelo meu programa, e sim olhar os produtos maduros. Falo sério.
O que levo disso
Olhando para trás, a frase mais importante de toda essa história não foi técnica. Foi a pergunta que me fiz naquela noite do caderno: estou resolvendo um problema que alguém realmente tem, ou construo algo porque posso?
Não sei se o ClinicPlusPlus vai virar um grande produto. Sei que começou com um problema que vi com meus próprios olhos, e que cada função que ele tem está ali porque alguém a usa todo dia. É um bom começo, mesmo que não seja um fim.
Se você dirige um consultório e se reconhece em alguma parte desta história, escreva para mim. Me interessa menos se você gosta do programa do que saber o que, no seu dia, atrapalha.
Este texto descreve o estágio do desenvolvimento no momento da publicação.