PEP, Prontuário Eletrônico do Paciente: arquitetura, CFM 2.314, SBIS-NGS2 e o checklist técnico completo

O PEP é mais que software, é a coluna vertebral digital da saúde

Em 2026, mais de 80% dos hospitais brasileiros acima de 100 leitos operam com algum tipo de PEP (Prontuário Eletrônico do Paciente). Mas só uma fração desses sistemas atende rigorosamente o que CFM 2.314/2022, SBIS-NGS2 e LGPD exigem.

A diferença entre "sistema de prontuário" e PEP de verdade é arquitetura. Esse post é o blueprint denso: o que precisa estar implementado no nível de sistema, banco, integração e operação para que um PEP atenda às exigências regulatórias e ainda escale.

Aprofunde também em LGPD na saúde: prontuário eletrônico, telemedicina e o checklist técnico definitivo e em Telemedicina no Brasil em 2026: a infraestrutura técnica que toda plataforma precisa ter.

A definição correta de PEP

PEP não é um sistema de cadastro de consultas. É o conjunto integrado de:

• Identificação unívoca do paciente (com vinculação CNS, CPF, foto, biometria)
• Histórico clínico longitudinal (todas as consultas, exames, procedimentos)
• Prescrição eletrônica com assinatura ICP-Brasil
• Anotação clínica estruturada (SOAP, problemas, condutas)
• Pedido e resultado de exames (laboratoriais e imagem)
• Registro de procedimentos (cirúrgicos, ambulatoriais)
• Faturamento (TISS/TUSS)
• Interoperabilidade (HL7, FHIR, RNDS)
• Compliance (LGPD, CFM, ANVISA, ANS)

Em uma única fonte da verdade acessada por múltiplos perfis com trilha de auditoria imutável.

A arquitetura técnica

[ APIs do PEP (REST + FHIR R4) ]
         ↓ entrada estruturada
[ Camada de aplicação ]
   - Identificação paciente (Master Patient Index, MPI)
   - Encontros (consultas, internações)
   - Documentos clínicos (CDA/FHIR)
   - Prescrições (assinatura ICP-Brasil)
   - Pedidos (lab, imagem)
   - Resultados (auto-incorporados via HL7)
   - Faturamento (TISS/TUSS)
   - Auditoria
         ↓ persistência
[ Banco principal: PostgreSQL ]
   - Particionamento por paciente_id (1M+ pacientes ativos)
   - Read replicas para leitura intensa
   - Logical replication para BI e RNDS
         ↓ assets clínicos
[ Object storage: S3 / Glacier ]
   - DICOM (imagem)
   - PDFs assinados
   - Fotos clínicas
   - Áudio de teleconsulta gravada
         ↓ vetor (RAG/IA)
[ pgvector ]
   - Embeddings de anotações clínicas
   - Busca semântica em prontuário
   - Sumarização clínica via LLM
         ↓ logs
[ Audit log imutável (WORM) ]
   - PostgreSQL com tabela append-only
   - Sync para S3 Object Lock (compliance NGS2)
         ↓ integrações externas
[ HL7 v2 / FHIR R4 ]
   - Laboratório (envio de pedido, retorno de resultado)
   - PACS (imagem)
   - Operadora (autorização, faturamento)
   - RNDS (Rede Nacional de Dados em Saúde)
   - Memed (prescrição eletrônica)
         ↓ identidade
[ Auth + ICP-Brasil ]
   - SSO via Keycloak / Auth0
   - MFA obrigatório
   - Certificado A1/A3 para assinatura
   - HSM para gestão de chave

Cada camada tem decisão crítica. Vamos passar.

O Master Patient Index (MPI)

Identificar o paciente unicamente é o desafio número 1 do PEP. Hospital recebe paciente:

• Com nome de mãe diferente em duas internações
• Com CPF errado da última visita
• Sem documento e identificação verbal
• Migrando de outra instituição com prontuário externo

MPI implementa deduplication probabilística:

• Score por nome (fuzzy matching com Levenshtein/Soundex)
• Score por nome da mãe
• Score por data de nascimento
• Score por CPF/CNS (quando presente)
• Score por endereço

Threshold superior a 0.95 = mesmo paciente. Entre 0.80–0.95 = revisão humana. Abaixo = paciente novo.

Implementação real:

• Postgres com extensão pg_trgm (trigram similarity)
• Função SQL similarity() para fuzzy match
• Pipeline de revisão manual com UI para fundir pacientes duplicados

Documentação clínica estruturada: SOAP digital

Anotação SOAP (Subjetivo, Objetivo, Avaliação, Plano) é o padrão. PEP moderno estrutura isso, não deixa em texto livre:

encontro:
  id: "encontro-2026-05-08-7a3..."
  paciente_id: "pat-001"
  data: "2026-05-08T14:30:00-03:00"
  tipo: "consulta_clinica_geral"
  profissional: { crm: "12345-SP", nome: "Dr. Carlos Mendes" }

  subjetivo:
    queixa_principal: "Dor abdominal há 3 dias"
    historia_doenca_atual: |
      Paciente refere dor em flanco direito iniciada há 3 dias,
      tipo cólica, intensidade 7/10, sem febre, sem náuseas.
    historia_pregresa: { hipertensao: true, diabetes: false, ... }
    medicamentos_em_uso: [ "Losartana 50mg 1x/dia" ]
    alergias: [ "AAS" ]

  objetivo:
    sinais_vitais:
      pa: { sistolica: 142, diastolica: 88 }
      fc: 84
      temp: 36.8
    exame_fisico: |
      AC: BNF, rítmicas, sem sopros.
      AR: MVF presentes bilateralmente.
      Abdome: doloroso à palpação em flanco direito, Giordano + à direita.

  avaliacao:
    hipotese_diagnostica: [ "CID-10: N20.0 - Cálculo renal" ]
    diferenciais: [ "Pielonefrite aguda", "Apendicite atípica" ]

  plano:
    exames_solicitados: [ "TC abdome sem contraste", "EAS", "Cre", "Ur" ]
    medicamentos_prescritos:
      - { nome: "Tramadol 50mg", posologia: "1 cap VO 8/8h se dor", duracao: "3 dias" }
    orientacoes: "Hidratação abundante. Retorno em 7 dias ou antes se piora."
    retorno: "2026-05-15"

A vantagem da estrutura:

• BI clínico (incidência de N20.0 por idade/sexo)
• Alertas automatizados (paciente com alergia recebeu medicamento da família?)
• Sumarização por LLM (resumo automático em 1 parágrafo do histórico)
• Interoperabilidade FHIR (estrutura traduz direto para Observation, Encounter, Condition, etc.)

Prescrição eletrônica com ICP-Brasil

O fluxo técnico:

1. Médico digita prescrição no PEP
2. Sistema gera PDF/A com layout regulamentado (incluindo QR Code)
3. Sistema gera hash SHA-256 do PDF
4. Sistema chama HSM (ou usa certificado A1 em memória segura) para assinar o hash com e-CPF do médico
5. CMS (Cryptographic Message Syntax) com assinatura é vinculado ao PDF
6. PDF assinado é armazenado em S3 com versionamento
7. Hash + metadata vai para banco principal e para registro Memed (se ativo)
8. Paciente recebe link para download do PDF assinado

Ferramentas:

• iText (Java) ou PyHanko (Python) ou node-signpdf (Node) para assinatura PDF
• HSM hospedado (AWS CloudHSM, Azure Dedicated HSM) ou YubiKey/SafeNet em casos menores
• Memed API ou Nexodata API para validação na drogaria

Compliance:

• Assinatura forte (e-CPF nível A1 ou A3)
• Carimbo de tempo confiável (TSA, Time Stamp Authority ICP-Brasil)
• Retenção mínima de 20 anos
• Verificação online acessível ao farmacêutico

Integração HL7 v2 e FHIR R4

PEP precisa conversar com:

• Sistema de Laboratório (LIS): pedido (ORM^O01), resultado (ORU^R01)
• PACS: pedido de imagem (ORM), retorno (ORU + WADO-RS para acessar DICOM)
• Sistema de farmácia interna: pedido de dispensação
• Operadoras: autorização (TISS XML), faturamento
• RNDS: eventos clínicos (FHIR R4)
• Equipamentos biomédicos: monitor cardíaco, ventilador (HL7 v2 ou proprietário)

HL7 v2: o padrão clássico

Mensagens texto com pipe-delimited:

MSH|^~\&|HOSP_PEP|HOSPITAL|LAB_LIS|LAB|20260508143000||ORM^O01|MSG001|P|2.5
PID|||PAT001||MENDES^JOAO^||19850302|M
ORC|NW|ORD001|||||1|||||DR^CARLOS^MENDES
OBR|1||LAB001|EAS^Exame de urina rotina|||20260508

Maduro, ubíquo, mas verbose. PEP serve via MLLP (Minimal Lower Layer Protocol) sobre TCP, ou cada vez mais via REST wrapper.

FHIR R4: o padrão moderno

JSON estruturado, RESTful, baseado em Resources (Patient, Encounter, Condition, Observation, MedicationRequest, etc.). RNDS usa FHIR R4.

{
  "resourceType": "MedicationRequest",
  "id": "med-req-001",
  "status": "active",
  "intent": "order",
  "subject": { "reference": "Patient/pat-001" },
  "medicationCodeableConcept": {
    "coding": [{
      "system": "https://anvisa.gov.br/medicamentos",
      "code": "1234567890",
      "display": "Tramadol 50mg cápsula"
    }]
  },
  "dosageInstruction": [{
    "text": "1 cápsula via oral 8/8h se dor",
    "timing": { "repeat": { "frequency": 3, "period": 1, "periodUnit": "d" }}
  }]
}

Em 2026, PEP novo deveria falar FHIR R4 nativamente e ter adapter HL7 v2 para legado.

Conformidade NGS2: os 80+ controles

NGS2 (Nível de Garantia de Segurança 2) é o padrão SBIS para PEP. Pontos críticos:

Autenticação

• MFA obrigatório (TOTP, SMS, biometria)
• Senha forte (12+ chars, mistura, troca em 90 dias)
• Bloqueio após 5 tentativas
• Sessão expira em 15 min idle

Autorização (RBAC granular)

• Médico vê só pacientes vinculados (encontros próprios)
• Recepção vê dados administrativos, NÃO dados clínicos
• Auditor vê tudo, mas com log diferenciado
• Quebra de sigilo em emergência: log + notificação ao DPO

Auditoria

• Log de toda ação: visualizar dado clínico, exportar, imprimir, alterar
• Retenção mínima 5 anos
• WORM (Write Once Read Many): log não pode ser apagado nem alterado

Integridade

• Assinatura digital em documentos relevantes
• Versionamento: alteração gera nova versão, original preservado
• Carimbo de tempo

Sigilo

• Criptografia em repouso (AES-256, gerenciada por HSM/KMS)
• Criptografia em trânsito (TLS 1.3)
• Chave por tenant em ambientes multi-tenant
• Backup criptografado

Continuidade

• Disponibilidade alvo 99,5% (NGS2)
• RPO < 1h, RTO < 4h
• Plano de contingência testado anualmente

Privacidade

• Pseudonimização para BI
• Anonimização para pesquisa
• Trilha de consentimento
• Direito do titular implementado (exportação, retificação, esquecimento quando aplicável)

A certificação NGS2 é renovada a cada 2 anos por auditoria SBIS. Em 2026, custa entre R$ 80k–R$ 240k a primeira certificação completa. Vale o investimento para hospitais que querem contratar com operadoras grandes ou rede pública.

Performance e escala

PEP de hospital grande (300+ leitos, 200k consultas/ano):

Métrica	Estimativa
Pacientes ativos	80k–250k
Encontros totais (histórico 10 anos)	1,5M–5M
Documentos clínicos	8M–30M
Tamanho do banco (sem imagem)	80GB–280GB
Imagem (DICOM), total	8TB–35TB
Queries simultâneas pico	600–1200
Latência alvo (busca paciente)	< 300ms
Latência alvo (abrir prontuário)	< 800ms

Decisões arquiteturais para sustentar isso:

• PostgreSQL particionado por paciente_id (range partition) ou por data
• Read replicas para queries de leitura e BI
• CDN para assets clínicos (DICOM via WADO-RS)
• Cache (Redis) para sessão e dados frequentes
• Background jobs (BullMQ ou Celery) para tarefas pesadas (geração PDF, OCR, sumarização IA)
• Search index (Postgres FTS para começo; Elastic se cresce)

IA integrada no PEP: o novo padrão

PEP de ponta em 2026 tem IA integrada em pontos específicos:

Sumarização clínica

LLM resume histórico longo de paciente em parágrafo de 1 página. Médico abre prontuário e vê resumo primeiro, detalhe se quiser.

Sugestão de CID-10

Médico digita queixa em texto livre. Sistema sugere CIDs prováveis. Médico aceita ou ajusta.

Detecção de interação medicamentosa

Antes de finalizar prescrição, IA cruza com medicamentos em uso e alergia. Alerta sobre risco.

Predição de readmissão

Modelo ML treinado em dados próprios calcula score de risco de readmissão em 30 dias.

Anotação por voz (ditado clínico)

Médico fala, sistema transcreve, IA estrutura em SOAP. Reduz tempo de digitação em 60%+.

Análise de imagem (em casos específicos)

Auxílio ao diagnóstico em radiologia (com supervisão médica obrigatória).

Tudo isso usando o blueprint de LLM em ERP sem inflar fatura: RAG, modelos plugáveis, observabilidade.

Conclusão

PEP é a peça mais importante da TI hospitalar, e a mais difícil de fazer bem. Atende compliance pesado (CFM, SBIS, LGPD), escala para milhares de usuários simultâneos, integra com 10+ sistemas externos, e ainda precisa ser usável por médico que tem 7 minutos por consulta.

A Bradata desenvolve PEPs e sistemas de saúde sob medida. Conheça nosso software de gestão hospitalar e aprofunde em LGPD na saúde e Telemedicina.

Se você é hospital, clínica ou operadora avaliando PEP novo ou substituição, fale conosco. Em 24 horas úteis enviamos análise inicial do seu cenário.

A Bradata é uma software house brasileira com profundidade em saúde, governo e setores regulados. Veja cases e soluções.

---

Fontes: Resolução CFM 1.821/2007 e 2.314/2022, SBIS Manual de Certificação NGS2 v4 (2024), HL7 FHIR R4 Specification, RNDS Documentação Técnica MS, LGPD (13.709/2018), Orientações ANPD 2024/2025, projetos internos Bradata.