A Obra-Prima – Anatomia da Aplicação de Saúde

Introdução: O Propósito de Tudo

Nos artigos anteriores, construímos a infraestrutura: dos cabos manga que conectavam os terminais, passando pelas placas multi-seriais que multiplicavam a capacidade do servidor, até as complexas configurações de BIOS e do próprio QNX. Mas toda essa infraestrutura existia por uma única razão: rodar a aplicação que era o coração da CompCet. Uma aplicação para a área da saúde com mais de 10 milhões de linhas de código, construída sobre uma pilha de tecnologia robusta – o compilador C86, o banco de dados C-tree e a biblioteca de interface Formplus – e, acima de tudo, reconhecida no mercado por uma característica singular: a velocidade.
Este artigo não é sobre configuração, mas sobre criação. É um mergulho na arquitetura e nas decisões de engenharia que transformaram linhas de código em uma das soluções de software mais performáticas de sua época.

A Arquitetura: Módulos Independentes, Dados Centralizados

A aplicação não era um único programa monolítico. Seguindo uma prática de boa engenharia de software, ela era dividida em vários programas executáveis, cada um responsável por um setor da clínica ou laboratório: havia o módulo de atendimento ao paciente (front-office), o módulo financeiro (faturamento), módulo de resultados de exames (laudos), entre outros.
Essa abordagem modular trazia enormes vantagens. Uma atualização no módulo de faturamento, por exemplo, não exigia a interrupção do trabalho da recepção. Cada programa era um "operário" especializado. E como esses operários conversavam entre si? A comunicação não era direta, mas sim mediada pelo banco de dados central. Quando um paciente era cadastrado na Recepção, seus dados eram gravados no C-tree. Segundos depois, o módulo de Laudos já podia ler esses mesmos dados para preparar um novo exame. O banco de dados era o grande pátio central onde todas as informações eram trocadas.

A Camada de Apresentação: A Magia do Formplus

Para que o usuário interagisse com o sistema através dos terminais coloridos do VTZ-180, era preciso uma ferramenta para "desenhar" as telas (leia também o artigo "Controlando a Tela – A Magia das Emulações e Sequências de Escape"). Essa ferramenta era a biblioteca Formplus. O Formplus fornecia um conjunto de componentes prontos para a criação de interfaces de texto (TUI - Text-based User Interface).
Em vez de programar manualmente a posição do cursor e a leitura de cada tecla, o desenvolvedor simplesmente definia uma estrutura, como a struct FormField ff[], onde cada linha descrevia um campo da tela: seu título ("Atendimento :"), sua posição (linha 2, coluna 1), seu tamanho, sua cor e a variável do programa associada a ele. O Formplus cuidava de todo o resto: renderizar a tela, navegar entre os campos, validar os dados e gerenciar as cores, liberando o programador para focar na lógica de negócio.

O Coração dos Dados: Gerenciamento com C-tree

A escolha do banco de dados era crucial para a performance. Embora a escolha do C-tree tenha sido anterior à minha chegada, a razão de seu sucesso era clara: liberdade e velocidade (leia também o artigo "O Mundo Antes do SQL – Uma Viagem ao C-tree e aos Bancos de Dados ISAM"). Conforme exploramos anteriormente, o C-tree era um poderoso motor ISAM que nos dava controle de baixo nível sobre os arquivos de dados (.dat) e seus índices (.idx), o que, nas mãos certas, oferecia uma performance imbatível.

Um arquivo de cabeçalho é a planta baixa do nosso banco de dados de Fichas. Nele, vemos a definição de múltiplos índices para o mesmo arquivo de dados:

• CODTAB: O índice primário, pelo código da ficha.
• DATTAB: Um índice pela data de entrada.
• PACTAB: Um índice pelo nome do paciente.
• MEDTAB: Um índice pelo código do médico.

Isso permitia buscas quase instantâneas. Encontrar um atendimento pelo seu número era direto. Mas encontrar todos os atendimentoss de um paciente específico, mesmo entre milhões de registros, também era extremamente rápido, pois o C-tree usava o índice PACTAB para ir diretamente aos registros corretos, sem precisar ler o arquivo de dados inteiro.
Em um ambiente com dezenas de usuários simultâneos, outro recurso do C-tree era vital: o Travamento de Registros (Record Locking). Conforme o manual, o C-tree gerenciava automaticamente os bloqueios nos nós da árvore de índices e permitia que a aplicação controlasse o bloqueio nos registros de dados. Isso impedia, por exemplo, que dois operadores na recepção tentassem alterar os dados do mesmo paciente exatamente ao mesmo tempo, garantindo a integridade dos dados.

As Inovações: O "Pulo do Gato"

A velocidade do sistema não vinha apenas das ferramentas, mas principalmente das soluções de engenharia criadas pela equipe. Duas inovações se destacam:

1. O Sistema de Laudos por Blocos de Texto:

A geração de laudos médicos era uma tarefa repetitiva, e a solução para isso, que herdei da ProSoft, era revolucionária. Eles criaram um sistema onde os laudos eram compostos por blocos de texto pré-definidos que o médico selecionava. O médico simplesmente selecionava os blocos necessários ("BLOCO A", "BLOCO C", "BLOCO F") e o sistema os montava, substituindo "variáveis" específicas (como nome do paciente ou resultados de um exame). O resultado era salvo como um arquivo de texto puro. Para recuperá-lo, em vez de uma busca lenta no banco de dados, o sistema acessava diretamente o arquivo no disco, o que era ordens de magnitude mais rápido. Inicialmente, a localização desses arquivos de texto era baseada em uma árvore de diretórios, mas organizada por uma fórmula matemática complexa sobre o número do atendimento. Era genial, mas difícil de dar manutenção. Anos depois, já na CompCet, eu aperfeiçoei esse sistema, tornando-o mais rápida e, crucialmente, mais intuitivo para a manutenção. A minha ideia foi simples e genial: organizar os laudos em uma árvore de diretórios baseada na data do atendimento: ano/mês/dia. Antes, na ProSoft, também era uma árvore de diretórios, mas baseada em uma fórmula matemática, como foi dito antes. Com isso, encontrar o arquivo de um laudo se tornou uma tarefa trivial e lógica, facilitando imensamente o trabalho de suporte.

2. O Gerador de Relatórios Dinâmicos:

Talvez a minha invenção de maior impacto tenha sido um gerador de relatórios integrado à aplicação. Numa época em que qualquer relatório novo exigia horas de um programador, compilação e a distribuição de uma nova versão do software, eu criei uma ferramenta que mudou as regras do jogo.
O meu gerador permitia que um operador de suporte, ou mesmo um usuário avançado, "desenhasse" um novo relatório diretamente no cliente. Ele selecionava os campos que queria, definia filtros e ordenações, e salvava essa "receita" do relatório no banco de dados. A partir daquele momento, qualquer usuário podia executar aquele relatório personalizado. Isso nos deu uma agilidade imensa. Um cliente precisava de uma relatório específico? O suporte podia criá-lo na hora, no local, sem a necessidade de envolver a equipe de desenvolvimento. Era o poder do SELECT e do GROUP BY dos bancos de dados relacionais, anos antes de eles se tornarem padrão no mercado de pequenas e médias empresas.

Conclusão

O sucesso da aplicação de saúde da CompCet/ProSoft é uma aula de engenharia de software. Ele demonstra que a performance não é fruto apenas de um sistema operacional rápido como o QNX, mas de uma arquitetura bem pensada. A escolha de ferramentas adequadas como o C-tree, o uso de bibliotecas de interface como o Formplus, a criação de camadas de abstração para acesso a dados e, acima de tudo, a busca incessante por soluções inovadoras para problemas reais – como o sistema de laudos e o gerador de relatórios – foram os ingredientes que, juntos, resultaram em uma obra-prima de software, o verdadeiro propósito de toda a infraestrutura que detalhamos neste livro.