Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

FHIR vs. uma base de dados médica personalizada

As suas próprias tabelas ou HL7 FHIR R4 para dados médicos: a mesma leitura armazenada de ambas as formas, os compromissos lado a lado, quando cada um é adequado e a divisão habitual entre a sua base de dados e o registo FHIR.

Uma equipa que inicia um produto de saúde depara-se geralmente com a mesma escolha cedo: desenhar as suas próprias tabelas para pacientes, medições e diagnósticos em PostgreSQL ou outra base de dados, ou armazenar dados médicos como recursos HL7 FHIR R4 desde o início. Um esquema personalizado é mais rápido no primeiro dia e adapta-se exatamente ao seu produto. O FHIR custa mais reflexão inicial e compensa sempre que os dados têm de sair do seu sistema, ser auditados, ser partilhados com consentimento ou ser lidos por alguém que não seja você. Esta página apresenta as compensações honestamente, com a mesma leitura armazenada de ambas as formas, e indica quando cada escolha é adequada.

Esta é uma questão diferente de qual servidor FHIR usar. Para isso, consulte Como o Anpheros se compara com outros servidores FHIR.

A mesma leitura, duas formas

Uma leitura de pressão arterial num esquema personalizado:

CREATE TABLE bp_readings (
  id          uuid PRIMARY KEY,
  user_id     uuid REFERENCES users(id),
  systolic    int,
  diastolic   int,
  measured_at timestamptz,
  created_at  timestamptz DEFAULT now()
);

Simples, rápida de consultar, exatamente o que a aplicação necessita. Depois surgem as questões a que a tabela não responde:

• Que dispositivo ou pessoa produziu o valor? Foi digitado pelo paciente, medido por um manguito, ou inserido por uma enfermeira?
• Qual era o valor antes de alguém o corrigir, e quem o corrigiu?
• Como é que um sistema clínico, um laboratório ou um segurador o lê? O que significa systolic no sistema deles?
• Como é que o paciente o partilha com a aplicação do seu médico e deixa de o partilhar no mês seguinte?
• Quando adiciona frequência cardíaca, peso, HbA1c e outras 200 medições, são 200 tabelas ou uma tabela genérica que desenha você mesmo?

A mesma leitura como FHIR R4:

{"resourceType": "Observation", "status": "final",
 "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
 "code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
 "subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
 "component": [
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
 "meta": {"versionId": "1"}}

Mais verboso, mas cada parte tem um significado que qualquer sistema FHIR partilha: LOINC indica o que foi medido, UCUM indica a unidade, meta.versionId inicia um histórico, e a mesma forma Observation contém as outras 200 medições. Com Anpheros, um recurso Provenance também regista quem o escreveu. Como armazenar registos médicos usando FHIR R4 explica detalhadamente.

Lado a lado

Quando um esquema personalizado é a escolha certa

• Os dados não são realmente médicos, ou não dizem respeito a uma pessoa. Planos de treino, conteúdos, um catálogo de produtos: utilize as suas próprias tabelas.
• Um protótipo de curta duração para testar se alguém quer o produto, com dados sintéticos e um plano para migrar.
• Dados que não se ajustam bem a modelos padrão, por exemplo, uma nova medição de investigação. O FHIR ainda pode transportá-los (Observation com o seu próprio sistema de códigos, ou Basic), mas uma tabela personalizada pode ser mais clara.
• Análise intensiva. Mesmo com o FHIR como sistema de registo, a maioria das equipas copia os dados para um data warehouse na sua própria estrutura para relatórios.

Quando o FHIR é a escolha certa

• Os dados são o registo de saúde de uma pessoa: medições, diagnósticos, medicamentos, alergias, resultados de laboratório, documentos.
• Vão sair do seu sistema: para o paciente, um médico, uma clínica, um laboratório, um segurador, um modelo de IA ou um concorrente quando o paciente se mudar.
• Precisa de mostrar quem escreveu o quê e o que mudou: auditorias, segurança clínica, litígios.
• Os pacientes concederão e revogarão o acesso por aplicação.
• Vende na União Europeia, onde o Espaço Europeu de Dados de Saúde espera que os registos sejam intercambiáveis em formatos standard.

O caminho intermédio habitual

A maioria dos produtos acaba por ter ambos, divididos por tipo de dados:

your database                         FHIR record (Anpheros)
─────────────                         ──────────────────────
users, sessions, settings             Patient
subscriptions, billing                Observation, Condition, MedicationStatement
product content, feature flags        AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column)     Provenance, Consent, history
caches and analytics copies  ◄─────── webhooks

A sua base de dados permanece pequena e com a forma do produto. O registo médico é standard, versionado e partilhável, e não teve de o construir. Backend e base de dados de aplicações médicas descreve esta divisão em detalhe, e Como construir uma API de saúde com TypeScript constrói-a.

O que é necessário para construir FHIR por conta própria

Escolher FHIR não significa escrever um servidor FHIR. As suas opções são um servidor de código aberto que executa, uma loja FHIR de um fornecedor de nuvem, uma plataforma de saúde de código aberto ou uma base de dados de saúde gerida como a Anpheros. Estas diferem em quem gere o consentimento, auditoria, proveniência, residência e integrações, o que Como a Anpheros se compara com outros servidores FHIR descreve.

Perguntas Frequentes

O FHIR é uma base de dados?

Não. O FHIR é um padrão para a estrutura e intercâmbio de dados de saúde: recursos, códigos e uma API REST. Um servidor FHIR ou uma base de dados FHIR gerida armazena os recursos e implementa a API por cima de uma base de dados real.

Posso armazenar recursos FHIR em PostgreSQL eu próprio?

Sim, como colunas JSON com os seus próprios índices, e alguns servidores de código aberto fazem exatamente isso. O trabalho está em tudo o que rodeia o armazenamento: parâmetros de pesquisa, versionamento, referências, validação, controlo de acesso por paciente e proveniência.

Posso começar com um esquema personalizado e migrar para FHIR mais tarde?

Pode, e muitas equipas fazem-no, mas a migração é um projeto de mapeamento: cada tabela precisa de códigos, unidades e autores que nunca registou. Armazenar dados médicos como FHIR desde a primeira funcionalidade custa menos do que convertê-los mais tarde.

Preciso de FHIR para cumprir o RGPD?

Não. O RGPD não exige um formato particular. O FHIR facilita o cumprimento de várias obrigações: portabilidade (o registo é exportado num formato padrão), controlo de acesso por finalidade e demonstração de quem processou quais dados.

Relacionado

• Esquema da base de dados FHIR: como os recursos FHIR são armazenados e indexados
• Como armazenar registos médicos usando FHIR R4
• Plataforma FHIR
• Como o Anpheros se compara com outros servidores FHIR
• Backend e base de dados de aplicações médicas
• API de Saúde

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card