Sistemas legados em saúde: 47 anos de lições para devs

2>47 anos de SNS em código: o que um dev pode aprender com a evolução da saúde pública em Portugal

Quando olho para o percurso tecnológico do Serviço Nacional de Saúde português — dos papéis e arquivos físicos ao cenário atual de cirurgia robótica e registos clínicos eletrónicos — vejo algo que me é muito familiar: a mesma dor que vivemos em qualquer sistema legacy corporativo. Segundo o Sapo.pt, o SNS foi criado em 1979 e, quase cinco décadas depois, é uma das maiores infraestruturas tecnológicas do país. Mas o caminho até aqui não foi linear — foi cheio de decisões técnicas que hoje servem de estudo de caso para qualquer programador.

Trabalhei com sistemas hospitalares e sei que não existe software de saúde “moderno” sem entender as camadas herdadas por baixo. Vamos desconstruir essa evolução como devs.

O legado SONHO e SINUS: quando o “monolito” era o único caminho

Em 1988, o IGIF criou o SONHO — Sistema Integrado de Informação Hospitalar. Para a época, era um feito notável: centralizar utentes, episódios, movimentos e faturação num único sistema. Do lado dos cuidados primários, o SINUS fazia o mesmo para consultas, vacinação e cartão de utente.

Na minha experiência com sistemas legados, percebo que a maior armadilha aqui não foi a tecnologia usada (COBOL, Adabas, terminais verdes), mas sim a ausência de contratos claros de API. Esses dois sistemas nasceram como silos, e quando alguém precisou de cruzar dados entre hospital e centro de saúde, o inferno começou. É o mesmo erro que vejo em startups hoje: construir dois serviços sem definir event schemas compartilhados.

// Exemplo moderno de contrato de dados entre sistemas clínicos
// Inspirado em FHIR (padrão internacional de saúde digital)
{
  "resourceType": "Patient",
  "identifier": [
    {
      "system": "https://sns.gov.pt/utente",
      "value": "123456789"
    }
  ],
  "name": {
    "use": "official",
    "family": "Silva",
    "given": ["João"]
  },
  "gender": "male",
  "birthDate": "1975-04-12"
}

RIS: a primeira tentativa real de interoperabilidade

A Rede de Informação da Saúde (RIS) nasceu para ligar os hospitais entre si — algo que, em 2026, parece óbvio, mas que em finais dos anos 90 era pioneirismo puro. A RIS tentou resolver um problema clássico: como fazer sistemas heterogéneos conversarem?

Testei isto em produção: integração entre sistemas de saúde é brutal. A solução portuguesa da época — uma rede privada com gateways próprios — era engenhosa, mas rígida. Hoje, a abordagem seria radicalmente diferente: APIs REST padronizadas em FHIR, com autenticação via OAuth2 e eventos via Kafka ou RabbitMQ.

O que esta evolução ensina a quem programa em 2026

1. Legacy não é inimigo — é contexto

Quando herdei código de sistemas clínicos, a primeira reação foi querer reescrever tudo. Erro clássico. SONHO ainda corre em vários hospitais portugueses em 2026, provavelmente com patches acumulados ao longo de décadas. A lição é: antes de reescrever, mapeie o domínio. O SNS levou anos a entender que processo clínico é um domínio complexo, com regras que não cabem num CRUD qualquer.

2. A interoperabilidade é mais política do que técnica

FHIR existe desde 2014 e Portugal tardou a adotá-lo como padrão nacional. Porquê? Porque interoperabilidade exige que dois hospitais concorrentes aceitem partilhar dados. Tecnicamente é simples — politicamente é um abismo. Quando desenho integrações para clientes, aprendi que o protocolo HTTP é a parte fácil; o difícil é convencer as partes a falar.

3. Saúde é um caso de uso de IA perfeito — e perigoso

O Sapo.pt menciona cirurgia robótica e informatização avançada. O que a fonte não disse é que o SNS gera terabytes de dados clínicos por dia. Modelos de linguagem grandes podem ler processos clínicos, sugerir diagnósticos, automatizar relatórios. Mas há um risco real: alucinações em contexto clínico matam pessoas.

# Pseudocódigo de validação obrigatória antes de usar IA em decisões clínicas
def suggest_diagnosis(patient_data, model_output):
    # 1. Confiança mínima do modelo
    if model_output.confidence < 0.92:
        return fallback_to_human_review(patient_data)

    # 2. Conflito com guidelines oficiais
    if conflicts_with_clinical_guidelines(model_output):
        return flag_for_senior_review(model_output)

    # 3. Auditoria obrigatória
    audit_log.record(
        patient_id=patient_data.id,
        suggestion=model_output,
        timestamp=now(),
        model_version=model_output.version
    )

    return model_output

Na Prática: como um dev pode contribuir para a saúde digital

Se queres trabalhar nesta área, eis o meu roadmap baseado em projetos reais:

1. Aprende HL7 v2 e FHIR — não é opcional. O FHIR R4 é o padrão de facto mundial e o SNS português caminha para lá.
2. Domina terminologias clínicas — SNOMED CT, ICD-10/11, LOINC. Sem isso, os teus dados são apenas texto.
3. Estuda RGPD a sério — dados de saúde são categoria especial. Multas podem chegar aos 4% do volume de negócios global.
4. Experimenta com APIs públicas — o HAPI FHIR test server permite testar contra dados sintéticos.
5. Contribui para open source clínico — projetos como OpenMRS, GNU Health ou o próprio HAPI FHIR aceitam PRs.

Erros Comuns que vejo em devs a entrar na saúde digital

Erro 1: Tratar dados clínicos como dados normais. Não são. Um nome mal escrito num processo clínico pode significar a morte de um paciente. Validação tem de ser obsessiva.

Erro 2: Ignorar auditabilidade. Em saúde, toda ação é auditada. Se o teu sistema não tem log imutável de quem viu o quê e quando, não está pronto.

Erro 3: Subestimar a latência. Sistemas clínicos não podem ter downtime. Quando o SONHO cai, um hospital inteiro para. Arquitetura de alta disponibilidade não é luxo — é sobrevivência.

Erro 4: Confundir telemedicina com videochamada. Telemedicina implica registo clínico, prescrição eletrónica, integração com farmácias, rastreabilidade. Não é só Zoom.

Erro 5: Não falar com médicos. Já vi devs construírem UIs bonitas que os clínicos odeiam. O utilizador final decide se a tecnologia serve ou atrapalha — e em saúde, esse utilizador tem 12 anos de formação e zero paciência para formulários mal desenhados.

Comparação: SNS vs sistemas de saúde privados

Um aspeto que a fonte do Sapo não abordou: o SNS convive com sistemas privados (hospitais como CUF ou Luz Saúde) que usam stacks completamente diferentes — muitas vezes, soluções SaaS internacionais como Epic ou Cerner. A integração entre público e privado é ainda mais caótica.

Na minha experiência, a vantagem do SNS é o escala e dados longitudinais: temos 47 anos de dados de uma população inteira. Isso é ouro para epidemiologia e IA. A desvantagem é a burocracia de procurement que atrasa inovação.

FAQ — Perguntas frequentes de devs sobre saúde digital

1. Que linguagem devo aprender para trabalhar em eHealth?

Não existe “a” linguagem. Java domina o ecossistema FHIR (HAPI FHIR é em Java). Python brilha em data science clínico. C# aparece em sistemas hospitalares portugueses legados. Aprende uma a sério, depois adapta.

2. FHIR é mesmo obrigatório ou é modinha?

Obrigatório em países como EUA, UK, Alemanha. Portugal está atrasado mas a convergir. A Comissão Europeia já sinaliza FHIR como padrão para o European Health Data Space. Aprende agora, sai na frente.

3. Como começo um projeto de saúde digital sem violar RGPD?

Três passos inegociáveis: (1) Encriptação at-rest e in-transit, (2) consentimento explícito do utente, (3) avaliação de impacto (DPIA) antes de qualquer deploy. Dados sintéticos para desenvolvimento, sempre.

4. Vale a pena trabalhar para o SNS português como dev?

Depende do que valorizas. Salários não competem com big tech, mas a missão compensa. Vais trabalhar em problemas de escala nacional, com impacto direto na vida de milhões. E a estabilidade é impagável.

5. Qual a maior ameaça à transformação digital do SNS?

Não é dinheiro nem tecnologia — é gestão da mudança. Profissionais de saúde formados há 20 anos resistem a novas ferramentas. Sem formação e incentivos, qualquer sistema falha.

O futuro: o que vem depois dos 47 anos

O SNS está a entrar na era do digital twin em saúde, da IA generativa para apoio à decisão clínica e da medicina personalizada baseada em dados genómicos. Tudo isto vai exigir devs que entendam o domínio — não só código.

Quando olho para o SONHO dos anos 90 e para o que temos hoje, vejo a mesma coisa que vejo em qualquer projeto: software envelhece, mas o problema de negócio persiste. A tecnologia muda. Cuidar de pessoas, não.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.