2. Solução Proposta

2.1 Objetivo Geral do Produto

O objetivo do produto é apoiar a integração e a digitalização da gestão da Clínica Escola de Psicologia da Faculdade Brasília, por meio de uma aplicação web responsiva que apoie o processo desde a inscrição do paciente até a entrega do relatório final de evolução.

A solução deverá:

Ampliar o aproveitamento das vagas ofertadas a cada semestre
Atacar prioritariamente as falhas de agendamento e de confirmação de presença que hoje produzem horários ociosos
Reduzir o esforço manual da coordenação, da secretaria, dos supervisores e dos estagiários
Preservar integralmente o caráter presencial do atendimento psicológico, conforme exigido pelo Conselho Regional de Psicologia

2.2 Objetivos Específicos (OE) do Produto

(OE1) Facilitar o acesso da comunidade de Santa Maria/DF ao processo de triagem psicológica, reduzindo barreiras de tempo e deslocamento na etapa de inscrição
(OE2) Apoiar a triagem dos inscritos, organizando as informações da inscrição e sinalizando pontos de atenção para subsidiar a priorização clínica realizada pela equipe da clínica, sem atribuição automática de prioridade pelo sistema
(OE3) Reduzir as faltas e os cancelamentos não informados, por meio de agendamento, lembretes e confirmação de presença
(OE4) Ampliar o aproveitamento das vagas ofertadas a cada semestre, com fila de espera organizada e realocação ágil das vagas liberadas
(OE5) Organizar o registro clínico e a supervisão, do acompanhamento das sessões até a geração do relatório final de evolução
(OE6) Subsidiar a gestão da clínica e a prestação de contas perante o Conselho Regional de Psicologia e o MEC, com base em indicadores confiáveis sobre o atendimento
(OE7) Assegurar o sigilo das informações dos pacientes, em conformidade com a LGPD e com as normas do Conselho Federal de Psicologia

2.3 Características de Produto (mapeadas com os Objetivos Específicos)

A solução proposta para a Clínica Escola da FBr deverá contemplar, de forma preliminar, as seguintes características:

ID	Característica de Produto (CP)	Descrição resumida	Valor de Negócio (VN) principal	Contribuição principal	Contribuição secundária
CP1	Inscrição on-line	Permitir que o interessado se inscreva pela internet, a partir de link divulgado no site e nas redes da FBr, informando dados cadastrais e a queixa, sem necessidade de deslocamento presencial.	Ampliação do alcance do projeto social e eliminação de uma ida presencial à instituição.	OE1	OE4
CP2	Triagem e sinalização de casos	Organizar as respostas do formulário de inscrição (queixa, urgência percebida, histórico informado) e sinalizar informações relevantes para a avaliação da equipe clínica. O sistema não atribui prioridade clínica de forma autônoma: a classificação de prioridade (vermelha, amarela, verde) é definida exclusivamente pela equipe da clínica, com base nas informações organizadas e sinalizadas pelo sistema.	Redução do esforço manual de organização das inscrições, sem delegar ao sistema uma decisão que afeta o acesso a atendimento psicológico.	OE2	OE1
CP3	Fila de espera e consulta de posição	Manter a fila de espera ordenada pela prioridade definida pela equipe clínica e permitir que o inscrito consulte apenas a sua própria posição, mediante mecanismo de autenticação (ex.: CPF combinado com código de verificação enviado ao e-mail ou telefone informado na inscrição), sem expor dados dos demais inscritos.	Transparência com a comunidade e redução dos contatos de acompanhamento à secretaria, sem expor informação sensível à posse isolada do CPF.	OE4	OE7
CP4	Agendamento, confirmação e remarcação	Apoiar o agendamento das sessões, envio de lembretes, confirmação de presença pelo paciente e registro de cancelamentos com justificativa, incluindo comunicação antecipada da ausência do estagiário.	Redução das faltas sem aviso e dos horários ociosos de estágio.	OE3	OE4
CP5	Distribuição de casos entre supervisores e estagiários	Apoiar a divisão dos casos entre os supervisores conforme a área de especialidade e a vinculação de cada paciente a um estagiário responsável.	Organização da reunião inicial de estágio e rastreabilidade da responsabilidade sobre cada caso.	OE5	OE2
CP6	Prontuário eletrônico	Manter o prontuário eletrônico do paciente, com os dados clínicos estruturados necessários ao acompanhamento do caso pelo estagiário responsável e pelo seu supervisor.	Centralização e padronização do registro clínico, com melhoria na qualidade da informação disponível para a supervisão.	OE5	OE6
CP7	Registro de evolução por sessão	Permitir o registro, pelo estagiário, da evolução de cada sessão realizada, associado ao prontuário do paciente.	Substituição do registro manual/disperso por um histórico estruturado e auditável da evolução do paciente.	OE5	OE2
CP8	Geração do relatório final de evolução	Gerar o relatório final de evolução ao término do ciclo de 8 a 10 sessões, consolidando os registros de evolução realizados ao longo do acompanhamento.	Eliminação da redigitação do relatório final e agilidade na entrega ao término do ciclo de atendimento.	OE5	OE6
CP9	Controle de assiduidade e alertas	Controlar as faltas de pacientes e de estagiários e emitir alerta quando o limite de duas faltas for atingido, sinalizando o desligamento do paciente e a liberação da vaga.	Aproveitamento das vagas liberadas e cumprimento das regras acadêmicas do estágio.	OE4	OE3
CP10	Registros administrativos do atendimento	Apoiar registros administrativos vinculados ao atendimento, incluindo: (i) registro do pagamento da taxa única de responsabilidade social de R$ 35, devida na primeira sessão, distinguindo quem efetivou e quem não efetivou o pagamento; (ii) emissão automática da declaração de comparecimento do paciente, com data, horário e nome do estagiário responsável.	Controle do requisito de início do atendimento e atendimento automatizado de uma demanda recorrente dos pacientes, sem esforço manual extra da secretaria.	OE6	OE4
CP11	Indicadores e relatórios institucionais	Consolidar indicadores da operação (vagas ocupadas, tempo de espera, evasão, casos por supervisor) e apoiar a extração dos relatórios exigidos pelo CRP e pelo MEC.	Apoio à gestão da clínica e à prestação de contas institucional.	OE6	OE4
CP12	Segurança, sigilo e controle de acesso	Incorporar perfis de acesso distintos para paciente, secretaria, estagiário, supervisor e coordenação, restringindo o prontuário ao estagiário responsável e ao seu supervisor. Além do controle por perfil, contempla: autenticação dos usuários internos; autorização por caso (não apenas por perfil genérico); trilha de auditoria de acessos e alterações no prontuário; criptografia de dados sensíveis em trânsito e em repouso; política de proteção de backups; prazos de retenção e descarte de dados conforme a LGPD; revogação de acesso ao final do vínculo do estagiário; segregação entre ambientes de teste e produção, com proibição de uso de dados reais em testes não controlados; e procedimento mínimo de resposta a incidentes de segurança. O detalhamento técnico desses itens será tratado como RNF na especificação de requisitos.	Redução do risco ético e legal no tratamento de dados sensíveis de saúde, para além do controle de acesso básico.	OE7	OE5
CP13	Continuidade de casos entre semestres	Permitir a transferência organizada de um caso e de seu histórico clínico quando o estagiário responsável conclui o estágio, preservando a continuidade do acompanhamento do paciente nos semestres seguintes.	Preservação do histórico do paciente e redução da descontinuidade de atendimento causada pela rotatividade semestral de estagiários.	OE5	OE6
CP14	Acessibilidade e usabilidade	Ser uma aplicação web responsiva, de uso simples e com recursos de acessibilidade, considerando o público em vulnerabilidade social e as exigências de acessibilidade avaliadas pelo MEC.	Inclusão de usuários com menor domínio tecnológico ou com deficiência visual e aderência à regulação.	OE1	OE7

Escopo do MVP

Considerando o prazo de um semestre letivo e a priorização acordada com o cliente, o Produto Mínimo Viável (MVP) será composto pelas características:

CP1, CP2, CP3, CP4, CP5, CP9, CP12 e CP14.

Essas características endereçam a dor mais crítica relatada pela coordenação: a inscrição, a organização da triagem, o agendamento, a confirmação de presença e o reaproveitamento das vagas liberadas, com controle de acesso compatível com a sensibilidade dos dados tratados.

As características CP6, CP7, CP8, CP10 e CP11 (prontuário eletrônico, registro de evolução, relatório final, registros administrativos e indicadores institucionais) compõem o escopo desejável, a ser tratado nas evoluções seguintes do produto dentro do horizonte da disciplina.

A característica CP13 (continuidade de casos entre semestres) representa uma visão de produto de mais longo prazo: depende de definições institucionais sobre o fluxo de encerramento e transferência de estágio ainda não fechadas com o cliente, e por isso não integra nem o MVP nem o escopo desejável imediato desta entrega.

Observação sobre a abrangência do MVP: o MVP reúne oito características que incluem organização de triagem, fila priorizada, agendamento com notificações, distribuição de casos, segurança de dados sensíveis e acessibilidade. Esse volume de escopo é reconhecido pela equipe como um risco de cronograma a ser reavaliado com mais critério na etapa de priorização formal da disciplina (Unidade 2).

2.4 Tecnologias a Serem Utilizadas

Conforme foi definido pela equipe, a stack tecnológica optada para o desenvolvimento da solução é definida por:

Front-end: TypeScript, com o framework Next.js, selecionado pela sua maturidade, documentação ampla e convenções bem estabelecidas de organização, reduzindo a curva de aprendizado para a equipe.
Back-end: TypeScript, com o framework NestJS, mantendo a linguagem do front-end, reduzindo a dispersão de trabalho da equipe entre as duas camadas da aplicação.
Banco de Dados: PostgreSQL, banco de dados relacional adequado à modelagem consistente dos perfis de acesso e das relações entre casos, sessões e responsáveis exigidas pelas características CP5 e CP12.

Controle de Versão e Documentação: GitHub como repositório central do código-fonte, diagramas e artefatos de requisitos, utilizando GitHub Projects para rastreamento de features e MkDocs/GitHub Pages para publicação da documentação do projeto.

2.5 Pesquisa de Mercado e Análise Competitiva

O mercado brasileiro de software para gestão de serviços de saúde é maduro e conta com soluções consolidadas de prontuário eletrônico, agenda e cobrança, inclusive produtos especializados em psicologia. Entretanto, essa oferta está organizada em torno do consultório privado e da clínica particular, nos quais quem atende é um profissional formado, responsável pela própria agenda e remunerado por sessão.

O contexto da Clínica Escola da FBr é estruturalmente diferente:

O atendimento é gratuito
É realizado por estagiários sob supervisão docente
O corpo de atendentes é renovado a cada semestre
A operação precisa prestar contas tanto ao paciente quanto à coordenação do curso

Principais soluções analisadas e suas fragilidades

Clínica nas Nuvens (Módulo Clínica-escola) É o concorrente mais próximo e o único identificado com um módulo dedicado a clínicas-escola. Contempla prontuário eletrônico adaptado à dupla finalidade clínica e pedagógica. Por outro lado, trata-se de uma plataforma ampla e multiprofissional, que carrega recursos irrelevantes para o caso (odontograma, faturamento TISS, emissão de NF-e, controle de estoque), aumentando a complexidade de uso e de treinamento. Sua comercialização ocorre por contrato, com preço divulgado apenas sob demonstração. O módulo se concentra no registro e na supervisão do atendimento, e não na porta de entrada do projeto social (solicitação pública de atendimento e triagem com fila de espera priorizada).

iClinic (Afya) Plataforma robusta, em nuvem, com teleconsulta, prontuário e adequação declarada à LGPD. Sua limitação central é o modelo de licenciamento, cobrado por profissional de saúde (planos entre R$ 99 e R$ 299 mensais por profissional – consulta realizada em agosto de 2026), o que torna o custo proibitivo para uma clínica escola com dezenas de estagiários rotativos. O modelo de dados presume o profissional autônomo como dono do atendimento, sem representar a relação estagiário–supervisor nem o vínculo do caso com o ciclo acadêmico.

PsicoManager Solução com melhor aderência ao domínio da psicologia, oferecendo agenda, prontuário psicológico, escalas, controle de sessões e recursos de inteligência artificial para apoio à evolução clínica. Contudo, está orientada ao psicólogo autônomo e à clínica privada, com forte ênfase em cobrança, repasse e gestão financeira — funcionalidades sem sentido em um serviço gratuito. Não contempla solicitação pública de atendimento, fila de espera institucional nem avaliação pedagógica do estagiário pelo supervisor.

Ferramentas genéricas (papel, planilhas, Google Agenda e WhatsApp) Constituem a alternativa de custo zero e adoção imediata e são o que mais se aproxima do processo atualmente praticado. Não oferecem, porém, prontuário estruturado, controle de acesso por perfil, trilha de auditoria ou garantias de sigilo compatíveis com o tratamento de dados sensíveis de saúde, exigidas pela LGPD e pelas resoluções do Conselho Federal de Psicologia. Também não eliminam a necessidade de deslocamento presencial do interessado.

Sistemas desenvolvidos sob demanda por outras instituições A literatura acadêmica registra iniciativas de sistemas de triagem e atendimento construídos especificamente para clínicas-escola, o que confirma a existência da demanda. Esses sistemas, no entanto, não são produtos disponíveis no mercado, não possuem distribuição, documentação pública ou manutenção garantida, e por isso não são reaproveitáveis pela FBr.

Quadro Comparativo

Critério de comparação	Clínica nas Nuvens (Módulo Clínica-escola)	iClinic (Afya)	PsicoManager	Ferramentas genéricas	Clínica Escola FBr (proposta)
Foco de mercado	Clínicas multiprofissionais de saúde, com módulo para clínica-escola	Clínicas e consultórios médicos	Psicólogo autônomo e clínica de psicologia particular	Uso geral, sem foco em saúde	Clínica escola de psicologia como projeto social
Modelo de custo	Contrato institucional, preço sob consulta	Assinatura mensal por profissional de saúde	Assinatura mensal por profissional ou por clínica	Gratuito ou já contratado	Solução própria da FBr, sem custo por usuário
Solicitação de atendimento e triagem	Parcial: foco no prontuário e na supervisão	Não: agenda voltada ao paciente já cadastrado	Não	Não	Sim: solicitação online, triagem e fila de espera priorizada
Hierarquia estagiário–supervisor	Sim	Não: presume profissional autônomo	Parcial: gestão de clínica, sem papel de estagiário	Não	Sim: perfis de estagiário, supervisor e coordenação
Continuidade de casos entre semestres	Não previsto explicitamente	Não	Não	Não	Sim (visão de produto — ver escopo do MVP)
Indicadores de gestão e responsabilidade social	Sim, com viés financeiro e assistencial	Sim, com viés financeiro	Sim, com viés financeiro	Não	Sim (escopo desejável)
Sigilo, LGPD e trilha de auditoria	Sim	Sim	Sim	Não: sem controle de acesso nem rastreabilidade	Sim: acesso por perfil e registro de auditoria (MVP)

Nota: as marcações "Sim" referem-se à solução completa, conforme concebida para a Clínica Escola FBr. Nem todas as capacidades estarão disponíveis já na primeira entrega — a seção "Escopo do MVP" especifica quais capacidades compõem o MVP, o escopo desejável e a visão de produto de mais longo prazo.

Diferenciais da Solução

A solução da Clínica Escola FBr irá se diferenciar pelos seguintes aspectos:

Fluxo desenhado para a clínica escola (parcialmente no MVP; visão completa é de médio prazo): em sua visão completa, o produto cobrirá o processo de ponta a ponta, da solicitação online de atendimento pelo cidadão até o encerramento ou encaminhamento do caso. No MVP desta entrega, o fluxo coberto vai da solicitação online até o agendamento, a confirmação de presença e a alocação do caso a um estagiário e seu supervisor; o registro de evolução e o relatório final (CP6 a CP8) fazem parte do escopo desejável das próximas iterações.
Papéis alinhados à estrutura acadêmica (no MVP): os perfis de solicitante, secretaria, estagiário, supervisor e coordenação, com controle de acesso (CP12), já fazem parte do MVP. A aplicação dessas regras de acesso ao conteúdo do prontuário se efetiva quando o CP6 for implementado, no escopo desejável.
Continuidade dos casos entre semestres (visão de produto): corresponde à CP13, ainda sem definição institucional fechada com o cliente; permanece como direção de evolução do produto, e não como entrega prevista no curto prazo.
Indicadores sociais e acadêmicos em lugar de gestão financeira (escopo desejável): corresponde à CP11; o foco dos relatórios será deslocado da cobrança para indicadores de valor institucional (volume de atendimentos, tempo médio de espera, taxa de absenteísmo e distribuição de casos por supervisor).
Custo total compatível com um projeto social (válido para toda a solução, independentemente da fase): como solução própria da instituição, o produto não implica assinatura por profissional, permitindo que o número de estagiários atendidos cresça a cada semestre sem custo marginal por usuário.

2.6 Viabilidade da Proposta

Os principais fatores que sustentam a viabilidade da proposta são o acesso facilitado ao cliente, a delimitação já negociada do escopo de MVP e a adoção de um modelo de entrega ágil ao longo do semestre. A equipe, embora enxuta, já definiu a stack tecnológica do projeto: TypeScript no front-end, com Next.js, e no back-end, com NestJS, além de PostgreSQL como banco de dados, o que reduz a dispersão de esforço ao concentrar o desenvolvimento em uma única linguagem entre as duas camadas da aplicação. O planejamento distribui o desenvolvimento em ciclos semanais que priorizam primeiro as funcionalidades que atacam o gargalo mais crítico apontado pela coordenação: o agendamento e a confirmação de presença dos pacientes.

É importante destacar, no entanto, que a viabilidade do projeto não deve ser sustentada apenas pela escolha de Next.js, NestJS e PostgreSQL. Essas escolhas favorecem a organização do código e reduzem a curva de aprendizado da equipe, mas o principal risco técnico do projeto está em outro lugar: na implementação segura das regras de triagem sem delegar decisão clínica ao sistema (CP2), no tratamento adequado de dados sensíveis de saúde (CP12), no funcionamento confiável do agendamento e das notificações (CP4) e na garantia de que uma vaga liberada seja de fato redirecionada ao próximo paciente elegível, e não apenas registrada como disponível. Esses riscos dependem mais de decisões de modelagem, de processo e de arquitetura de segurança do que da linguagem ou do framework escolhidos, e serão detalhados na especificação de requisitos não funcionais.

Para conter esse risco, a equipe optou por avançar de forma modular, entregando e validando cada bloco isoladamente antes de integrá-lo ao restante do sistema. A escolha de Next.js e NestJS, frameworks maduros e amplamente documentados dentro do ecossistema TypeScript, favorece esse avanço modular, já que ambos seguem convenções bem estabelecidas para a organização de módulos, controladores e rotas, o que tende a reduzir a curva de aprendizado mesmo nos pontos em que o domínio técnico da equipe ainda está em formação. O uso de um banco relacional também é compatível com a necessidade de modelar de forma consistente os perfis de acesso — paciente, secretaria, estagiário, supervisor e coordenação — e as relações entre casos, sessões e responsáveis, exigidas pelas características CP5 e CP12.

Diante desse cenário, a viabilidade do projeto passa a depender de três condições práticas:

Manter o escopo do MVP fechado no conjunto de funcionalidades já priorizado com o cliente, resistindo à antecipação de itens do escopo desejável;
Sustentar uma cadência regular de validações com a Faculdade Brasília, aproveitando a disponibilidade e a agilidade de resposta já observadas durante o levantamento;
Monitorar, ao longo do semestre, a complexidade acumulada do MVP — que ainda reúne oito características, incluindo triagem, fila priorizada, agendamento, notificações, distribuição de casos, segurança de dados sensíveis e acessibilidade — para que a entrega das funcionalidades não comprometa o tratamento adequado da segurança e do sigilo (CP12).

2.7 Benefícios Esperados

Para o cliente: ampliar a capacidade de gestão da Clínica Escola de Psicologia da FBr, centralizando informações relacionadas à inscrição, seleção, agendamento e acompanhamento dos pacientes. A solução deverá contribuir para a redução de processos manuais, melhorar o controle sobre faltas, cancelamentos e vagas disponíveis, facilitar a realocação de pacientes e proporcionar maior rastreabilidade dos atendimentos. Também se espera melhorar o controle das atividades dos estagiários e fornecer informações mais organizadas para supervisores e coordenação, criando melhores condições para a continuidade e expansão dos serviços prestados pela Clínica Escola.
Para os usuários: proporcionar aos pacientes uma experiência mais simples, acessível e transparente desde a inscrição até o acompanhamento do atendimento, facilitando o acesso às informações sobre agendamentos, confirmações, cancelamentos e situação na fila de espera. Para estagiários, supervisores e profissionais envolvidos na operação da clínica, espera-se reduzir tarefas manuais e facilitar o acesso às informações necessárias para organização e acompanhamento dos atendimentos, respeitando os diferentes níveis de acesso e o sigilo das informações dos pacientes.