Software para clínicas: requisitos e compliance CFM

Desenvolver software para clínicas médicas é uma das tarefas mais exigentes do universo de sistemas de gestão setorial. Ao contrário de um ERP de varejo ou de uma ferramenta de controle financeiro, o software médico precisa atender a um conjunto de obrigações regulatórias que vai muito além da Lei Geral de Proteção de Dados. Antes mesmo de pensar em features como agendamento online ou dashboard de indicadores, o desenvolvedor precisa garantir que o sistema está em conformidade com as resoluções do Conselho Federal de Medicina, com os padrões da ANS para cobrança de planos de saúde e com as exigências de auditoria de prontuários.

Ignorar esses requisitos não é apenas um risco jurídico — é um risco à operação da clínica. Um software que não gera prontuário eletrônico válido pode inviabilizar a participação da clínica em convênios. Um sistema sem rastreabilidade de acesso pode resultar em sanções do CFM. Este artigo mapeia os requisitos obrigatórios para quem está construindo ou contratando software médico no Brasil.

CFM 1821/07: Requisitos do Prontuário Eletrônico

A Resolução CFM 1821/2007 estabelece as normas técnicas para o uso de sistemas informatizados para guarda e manuseio do prontuário dos pacientes. É o documento que define o que precisa existir em qualquer sistema que se proponha a substituir o papel no ambiente clínico.

Os requisitos principais da norma incluem:

• Autenticação inequívoca: todo registro no prontuário deve ser associado a um profissional identificado, preferencialmente com certificado digital ICP-Brasil.
• Imutabilidade: entradas no prontuário não podem ser apagadas. Correções devem ser feitas por meio de adendos com carimbo de data/hora e identificação do autor.
• Backup e redundância: o sistema deve garantir recuperação dos dados em caso de falha, com periodicidade de backup documentada.
• Interoperabilidade: exportação em formato HL7 ou XML estruturado para permitir continuidade do cuidado entre instituições.

Na prática, isso significa que a entidade ProntuarioEntry no banco de dados deve ser append-only. Nunca se faz UPDATE em registros clínicos — qualquer atualização gera um novo registro com referência ao anterior.

CREATE TABLE prontuario_entries (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  paciente_id UUID NOT NULL REFERENCES pacientes(id),
  medico_id UUID NOT NULL REFERENCES medicos(id),
  conteudo TEXT NOT NULL,
  tipo VARCHAR(50) NOT NULL, -- 'anamnese', 'evolucao', 'prescricao', 'laudo'
  entrada_anterior_id UUID REFERENCES prontuario_entries(id),
  assinado_em TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  hash_conteudo CHAR(64) NOT NULL, -- SHA-256 para verificação de integridade
  certificado_digital TEXT -- base64 do certificado ICP-Brasil, quando disponível
);

A coluna entrada_anterior_id permite rastrear a cadeia de adendos, e hash_conteudo garante que o conteúdo não foi alterado após a assinatura.

LGPD em Dados de Saúde: Dados Sensíveis e Obrigações

A Lei 13.709/2018 classifica dados de saúde como dados pessoais sensíveis, o que impõe um conjunto adicional de obrigações em relação a dados pessoais comuns. O tratamento de dados sensíveis exige base legal específica — no contexto médico, geralmente a tutela da saúde (Art. 11, II, f) ou o consentimento explícito e específico do titular.

Para software clínico, as principais implicações são:

Consentimento granular: o paciente deve consentir separadamente para tratamento clínico, compartilhamento com convênio, comunicações de marketing e uso de dados para pesquisa. Um único checkbox "aceito os termos" não é suficiente.

Minimização de dados: o sistema não deve coletar mais do que o necessário. Integrar dados de geolocalização com o prontuário, por exemplo, exige justificativa clara.

Portabilidade: o paciente tem direito de receber seus dados em formato estruturado e legível. O sistema deve oferecer exportação de prontuário completo em PDF ou JSON.

Logs de acesso: cada acesso a dados de saúde deve ser registrado com identificação do usuário, data/hora, dado acessado e finalidade declarada.

Relatório de Impacto (RIPD): para sistemas que processam dados de saúde em escala, a ANPD pode exigir o Relatório de Impacto à Proteção de Dados Pessoais antes do lançamento.

A recomendação prática é isolar os dados sensíveis em tabelas próprias com permissões de acesso granulares no banco de dados, aplicando criptografia em repouso (AES-256) para campos como diagnósticos, prescrições e histórico psicológico.

Integrações TISS/TUSS: Cobrança de Planos de Saúde

O padrão TISS (Troca de Informações em Saúde Suplementar) é o formato exigido pela ANS para comunicação entre prestadores de serviço e operadoras de planos de saúde. É essencialmente um protocolo de XML estruturado para envio de guias de consulta, SADT (exames e terapias) e honorários médicos.

O padrão TUSS (Terminologia Unificada da Saúde Suplementar) é o dicionário de procedimentos — cada procedimento clínico tem um código TUSS que precisa constar na guia eletrônica enviada ao convênio.

Para implementar integração TISS no software da clínica:

1. Cadastro de procedimentos com código TUSS: o sistema precisa de tabela de procedimentos mapeada para os códigos TUSS vigentes, que são atualizados periodicamente pela ANS.
2. Geração de guias XML: o sistema deve gerar XMLs no schema TISS v3 (atualmente v3.05.00) para cada tipo de guia — consulta, SADT, resumo de internação.
3. Envio e tracking: as operadoras disponibilizam webservices SOAP para recepção das guias. O sistema precisa tratar os retornos de lote (aceito, rejeitado, pendente) e rastrear o status de cada guia.
4. Glosa e recurso: o sistema deve permitir contestação de glosas (cobranças negadas) com registro de protocolo.

Muitas clínicas utilizam intermediários como o sistema Tasy ou webservices de terceiros para abstração do protocolo TISS. Se o seu sistema for crítico ou de alto volume, a implementação direta pode ser mais econômica a longo prazo.

Auditoria e Rastreabilidade: Quem Viu o Quê e Quando

O prontuário médico é um documento legal. Em casos de processos judiciais contra médicos ou clínicas, o histórico de acesso ao prontuário pode ser determinante. O sistema precisa registrar não apenas quem fez alterações, mas quem visualizou os dados, mesmo sem modificá-los.

A tabela de auditoria precisa ser:

• Imutável: nem o administrador do sistema pode deletar logs de acesso.
• Tamper-evident: idealmente com hash encadeado (como blockchain simplificado) ou envio para storage externo imutável (S3 com Object Lock, por exemplo).
• Detalhada: registrar endpoint acessado, IP, user agent, ID do paciente acessado e o papel (role) do usuário no momento do acesso.

Logs de auditoria também são exigidos pela CFM para investigações disciplinares. Um médico pode ser notificado pelo Conselho sobre acesso indevido ao prontuário de um paciente com o qual não tem relação de atendimento — e o sistema precisa fornecer esse histórico.

Além da auditoria de acesso, o sistema deve implementar controle de acesso baseado em papéis (RBAC) com granularidade suficiente para distinguir, por exemplo, um recepcionista (acessa agendamento, não acessa conteúdo clínico) de um médico assistente (acessa prontuário completo dos seus pacientes) de um administrador (acessa logs, não acessa conteúdo clínico diretamente).

Conclusão

Construir software para clínicas médicas no Brasil é um desafio de engenharia e compliance que não se improvisa. A combinação de CFM 1821/07, LGPD para dados sensíveis, padrão TISS/TUSS para convênios e exigências de auditoria cria um conjunto de requisitos que precisa estar no escopo desde o dia zero — não como retrofitting após o lançamento.

O custo de ignorar esses requisitos não é apenas regulatório. Um sistema não conforme com TISS pode fazer a clínica perder contratos com convênios. Um prontuário sem imutabilidade pode inviabilizar a defesa do médico em um processo. Um sistema sem logs de acesso pode resultar em sanção do CFM.

A SystemForge desenvolve software de gestão setorial com esse nível de profundidade desde a fase de especificação. Se você está construindo ou reformulando o sistema da sua clínica, entre em contato para uma análise dos requisitos técnicos e regulatórios antes de escrever a primeira linha de código.