Case: sistema de gestão hospitalar com PEP, HL7 FHIR e gestão de leitos

O cenário inicial

Um hospital de médio porte no interior de São Paulo, 180 leitos, operava com três sistemas desconectados: um ERP administrativo dos anos 2000, prontuários em papel digitalizados como PDF, e planilhas Excel para controle de leitos. O faturamento TISS era feito por uma pessoa que re-digitava dados manualmente. Erros de faturamento consumiam cerca de R$ 120 mil por mês em glosas.

A diretoria queria um sistema unificado. Avaliaram soluções de mercado (MV, Tasy, Philips), mas os orçamentos passavam de R$ 2 milhões só em licenciamento, sem contar customização. O prazo de implantação estimado era de 18 a 24 meses. Não cabia no orçamento nem no tempo.

Fomos chamados para construir sob medida. O escopo: prontuário eletrônico do paciente (PEP), gestão de leitos, farmácia hospitalar, agendamento de consultas e exames, e integração HL7 FHIR com a RNDS.

Por que essa stack

Next.js no frontend

O hospital tinha perfis de usuário com necessidades muito diferentes. Médicos precisam de telas rápidas para evoluir prontuário entre um paciente e outro. Recepção precisa de formulários densos. Enfermagem precisa de checklist visual para aprazamento. Administração precisa de dashboards.

Next.js com App Router nos deu Server Components para as telas pesadas de relatório (renderização no servidor, sem carregar bundles JS desnecessários no navegador) e Client Components para interações em tempo real como o quadro de leitos.

.NET no backend

A escolha de .NET 8 não foi por preferência pessoal. Foi pragmática. O ecossistema de saúde no Brasil tem bibliotecas .NET maduras para HL7 v2 parsing, TISS XML generation, e assinatura digital ICP-Brasil. A biblioteca Firely SDK para FHIR R4 é a mais robusta do mercado e roda nativamente em .NET.

O endpoint de busca de prontuário precisava devolver dados de um paciente com 15 anos de histórico em menos de 200ms. .NET com AOT compilation entregou p95 de 87ms.

PostgreSQL

Hospital não é lugar para banco eventualmente consistente. Prescrição médica errada pode matar. PostgreSQL com serializable isolation level nos deu a garantia que precisávamos. Usamos particionamento por data para a tabela de evolução clínica (que cresce ~50 mil registros por mês) e JSONB para dados semi-estruturados como resultados de exames laboratoriais, onde o schema varia entre laboratórios.

Docker

Toda a infraestrutura roda em containers Docker com Docker Compose em dois servidores bare-metal no datacenter do hospital. On-premise por requisito regulatório: LGPD para dados sensíveis (Art. 11) combinada com resoluções do CFM. O jurídico vetou AWS/Azure por questões de soberania de dados.

O prontuário eletrônico

O PEP foi o módulo mais complexo. Não é só um formulário de texto livre. É um grafo de dados clínicos interconectados.

Estrutura do prontuário

Cada atendimento gera um registro com: anamnese estruturada (usando templates por especialidade), exame físico (com campos numéricos validados por faixa), hipótese diagnóstica (codificada em CID-10), prescrição (medicamentos, dietas, cuidados de enfermagem), evolução (SOAP: Subjetivo, Objetivo, Avaliação, Plano) e encaminhamentos.

A prescrição eletrônica foi onde gastamos mais tempo. O sistema precisa cruzar: alergias do paciente, interações medicamentosas (usamos a base de dados do Micromedex via API), protocolos do hospital, e estoque da farmácia. Se o médico prescreve dipirona para um paciente alérgico, o sistema bloqueia. Se prescreve um antibiótico que está em falta na farmácia, alerta e sugere alternativa.

Assinatura digital

Toda evolução e prescrição precisa de assinatura digital ICP-Brasil (Resolução CFM 2.314/2022). Implementamos com certificado A3 em token USB para médicos e certificado em nuvem (BirdID) como alternativa. O fluxo: médico finaliza a prescrição, o sistema gera o hash SHA-256 do documento, o certificado assina, e o documento assinado é armazenado com carimbo de tempo.

Integração HL7 FHIR

A integração com a RNDS (Rede Nacional de Dados em Saúde) exige FHIR R4. Implementamos resources para Patient, Encounter, Condition, MedicationRequest, Observation e DiagnosticReport.

O ponto mais trabalhoso foi o mapeamento de terminologias. O hospital usava uma tabela interna de procedimentos que não batia com TUSS/SIGTAP. Construímos um módulo de "de-para" com interface para o time administrativo fazer o mapeamento manualmente, com sugestões automáticas baseadas em similaridade de texto.

A comunicação com a RNDS usa certificado digital do hospital (e-CNPJ) e o fluxo OAuth2 da plataforma. Cada registro de atendimento gera um Bundle FHIR que é enviado de forma assíncrona via fila (RabbitMQ). Se a RNDS rejeita, o sistema re-enfileira com backoff exponencial e gera alerta para o time de TI.

Gestão de leitos

O quadro de leitos é uma tela em tempo real que mostra todos os 180 leitos do hospital em grid visual, com cores por status: livre (verde), ocupado (azul), em limpeza (amarelo), manutenção (vermelho), bloqueado (cinza).

Tecnicamente, usamos WebSocket (SignalR no .NET) para atualizar o quadro em tempo real. Quando a enfermagem registra alta de um paciente, o leito muda para "em limpeza". Quando o time de higienização confirma a limpeza pelo app mobile (React Native, simplificado), muda para "livre". O sistema de internação puxa automaticamente a fila de espera e sugere alocação baseada em: especialidade, tipo de leito (enfermaria, apartamento, UTI), convênio do paciente.

Antes do sistema, o tempo médio entre alta e nova internação era de 6h20min. Depois, caiu para 2h45min. O ganho financeiro foi direto: mais giros de leito significam mais faturamento.

Farmácia hospitalar

O módulo de farmácia controla estoque com rastreabilidade por lote e validade (ANVISA RDC 430/2020). O fluxo completo: prescrição médica gera pedido para farmácia, farmacêutico valida (checagem de dose, via, frequência), sistema separa por paciente (dose unitária), enfermagem confirma administração via leitura de código de barras no leito.

Implementamos alertas automáticos para: medicamentos próximos do vencimento (30, 15 e 7 dias), estoque abaixo do ponto de pedido, e curva ABC para otimizar compras. O estoque é valorizado por custo médio ponderado, integrado com o módulo financeiro.

Agendamento

O módulo de agendamento controla consultas ambulatoriais, exames e cirurgias. A parte não trivial foi o agendamento cirúrgico: cada cirurgia precisa de sala, equipe médica, equipamentos específicos, e disponibilidade de leito pós-operatório. O sistema faz a verificação cruzada de todos esses recursos antes de confirmar o agendamento.

Para consultas ambulatoriais, implementamos agendamento online (portal do paciente) com confirmação por SMS 24h antes. A taxa de no-show caiu de 32% para 14%.

Decisões que doeram

Não usamos microserviços. Com um time de 6 desenvolvedores, manter 8 serviços em produção seria insustentável. Fizemos um monolito modular em .NET com separação por domínios. Cada módulo tem seu próprio schema no PostgreSQL.

Não migramos os 12 anos de prontuários em papel. Construímos um "viewer" de prontuários legados que exibe os PDFs antigos dentro do novo sistema, com indexação por paciente e data. Os dados estruturados começaram do zero.

A resistência dos médicos exigiu 6 semanas de treinamento presencial. Criamos atalhos de teclado para as 20 operações mais frequentes. Depois de 3 meses, a adesão chegou a 94%.

Números após 8 meses em produção

O sistema processa 1.200 atendimentos por mês. Tempo de carregamento de prontuário completo: 140ms. Uptime: 99.7%. Glosas no faturamento TISS caíram de R$ 120 mil/mês para R$ 18 mil/mês. ROI em 11 meses.

A stack completa: Next.js 14, .NET 8, PostgreSQL 16, RabbitMQ, Redis, SignalR, Docker, React Native (app de higienização), Firely SDK (FHIR), Micromedex API.

---

Precisa de um sistema hospitalar sob medida? Fale com a Bradata.