# FHIR vs HL7 v2: diferenças práticas

> Mensagens HL7 v2 e recursos FHIR comparados para programadores: formato, transporte, o mesmo resultado de laboratório em ambos, armadilhas de tradução e onde o Anpheros aceita v2.

Source: https://developers.anpheros.com/pt/guides/fhir-vs-hl7-v2

**HL7 v2 é o formato de mensagem que os sistemas hospitalares trocam desde o final dos anos 80 — eventos delimitados por pipe, como "paciente admitido" ou "resultado de laboratório pronto", enviados entre sistemas através de uma ligação de rede — enquanto HL7 FHIR é um padrão de API web onde as aplicações leem e escrevem recursos como Paciente e Observação sobre HTTPS em JSON.** Não são alternativas que se escolhem uma vez: a maioria dos hospitais ainda opera com v2 internamente, as novas aplicações e APIs voltadas para o paciente usam FHIR, e o trabalho de integração é frequentemente a tradução de um para o outro. Esta página compara-os nos pontos que importam quando escreve código, mostra os mesmos dados em ambos e explica onde o Anpheros aceita v2.

## Lado a lado

| | HL7 v2 | HL7 FHIR R4 |
|---|---|---|
| Estilo | Mensagens acionadas por eventos (admissão, pedido, resultado) | Recursos que cria, lê, atualiza, pesquisa |
| Formato | Segmentos de texto separados por quebras de linha, campos por `\|`, componentes por `^` | JSON (ou XML) |
| Transporte | Geralmente MLLP sobre TCP dentro da rede hospitalar | HTTPS REST |
| Consulta | Limitada; os sistemas enviam principalmente | Parâmetros de pesquisa, `_include`, histórico |
| Segurança | Nível de rede (VPN, ligações privadas) | OAuth 2.0 / SMART on FHIR, TLS, escopos |
| Flexibilidade | Muitos campos opcionais e segmentos Z locais; cada interface é negociada | Recursos base mais perfis (US Core, IPS, IGs europeus) |
| Utilizadores típicos | Sistemas EHR, laboratório, radiologia, faturação dentro de um hospital | Aplicações, APIs de acesso do paciente, intercâmbio inter-organizações, IA |

As mensagens v2 mais comuns:

| Mensagem | Significado | Recursos FHIR mais próximos |
|---|---|---|
| ADT^A01, A03, A08 | Admissão, alta, atualização do paciente | `Patient`, `Encounter` |
| ORM / OML | Pedir um teste | `ServiceRequest` |
| ORU^R01 | Resultado pronto | `Observation`, `DiagnosticReport` |
| SIU | Agendamento | `Appointment` |
| MDM | Documento | `DocumentReference` |

## O mesmo resultado em ambos

Uma linha de resultado ORU^R01 (segmento OBX):

```
OBX|1|NM|2093-3^Cholesterol^LN||212|mg/dL|<200|H|||F|||20261002074500
```

O mesmo resultado como uma Observação HL7 FHIR R4, como o Anpheros o armazena após importar essa mensagem:

```json
{
  "resourceType": "Observation",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "2093-3", "display": "Cholesterol [Mass/volume] in Serum or Plasma"}], "text": "Cholesterol"},
  "effectiveDateTime": "2026-10-02T07:45:00Z",
  "valueQuantity": {"value": 212.0, "unit": "mg/dL"},
  "interpretation": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation", "code": "H"}]}],
  "referenceRange": [{"high": {"value": 200.0, "unit": "mg/dL"}}]
}
```

Campo a campo: OBX-3 torna-se `code`, OBX-5 e OBX-6 tornam-se `valueQuantity`, OBX-7 `referenceRange`, OBX-8 `interpretation`, OBX-11 `status`, OBX-14 `effectiveDateTime`. O HL7 publica um [guia de implementação oficial do HL7 Version 2 para FHIR](https://build.fhir.org/ig/HL7/v2-to-fhir/) com mapeamentos para segmentos, tipos de dados e vocabulários.

## Onde as traduções falham

- **Fuso horários.** Timestamps v2 como `20261002074500` frequentemente não incluem um offset; tem de conhecer a zona do remetente. FHIR requer uma zona sempre que um tempo está presente. (Anpheros lê um tempo v2 sem zona como UTC; envie o offset se o tiver.)
- **Códigos locais.** Muitos laboratórios colocam os seus próprios códigos em OBX-3 em vez de LOINC. Uma boa tradução mantém o código local e mapeia-o para LOINC quando possível, em vez de o descartar.
- **Envios repetidos.** Remetentes v2 retransmitem em caso de timeouts. Sem um identificador estável por resultado, um FHIR store enche-se de duplicados.
- **Opcionalidade de tudo.** O mesmo campo pode estar vazio, repetido ou ser usado de forma diferente por dois remetentes. Valide o lado FHIR; o [validador FHIR R4](https://developers.anpheros.com/tools/fhir-validator) mostra o que falta num recurso traduzido.
- **Correções.** O estado do resultado v2 `C` (corrigido) deve atualizar a Observação existente e manter o seu histórico, não criar uma segunda.

## Quando usar o quê

- **Dentro de um hospital, entre sistemas existentes:** v2 é geralmente o que os sistemas utilizam. Um motor de integração roteia e transforma mensagens.
- **A construir uma aplicação, uma API de acesso ao paciente ou qualquer coisa que atravesse organizações:** FHIR, com OAuth e consentimento.
- **Alimentar IA ou análises:** FHIR, porque é consultável, codificado e versionado.
- **Ambos:** o padrão comum no mundo real — receber v2 do laboratório ou EHR, armazenar FHIR, servir FHIR a aplicações.

## Onde o Anpheros se encaixa

O Anpheros armazena registos de pacientes como FHIR R4 e aceita um tipo de mensagem HL7 v2: **ORU^R01 resultados de laboratório**, enviados via HTTPS para o [conector de laboratório](https://developers.anpheros.com/pt/guides/lab-connector) (`POST /v1/patients/{id}/labs/import` com `Content-Type: x-application/hl7-v2+er7`). Cada OBX torna-se uma Observação de laboratório com código LOINC, intervalo de referência e interpretação; o ID do relatório é mantido na proveniência e relatórios reenviados são ignorados. Um resultado corrigido (OBX-11 = `C`) com um novo valor é armazenado como uma nova Observação com estado `amended`; o original permanece como estava, portanto, se a sua fonte enviar correções, marque a Observação anterior `entered-in-error` ou atualize-a através da API FHIR. Um exemplo prático é a [API de resultados de laboratório](https://developers.anpheros.com/pt/guides/lab-results-api).

Não aceita outras mensagens v2 (ADT, pedidos, agendamento), não escuta em MLLP e não envia v2. Para estes casos, um motor de integração à frente do Anpheros traduz para FHIR e escreve através da API.

## Perguntas Frequentes

### O FHIR está a substituir o HL7 v2?
Não em breve. O v2 continua a ser a espinha dorsal da maioria dos hospitais porque funciona e está integrado nos sistemas existentes. O FHIR está a crescer à sua volta — em aplicações, acesso de pacientes e intercâmbio entre organizações — e os dois coexistem, muitas vezes com tradução entre eles.

### O que é MLLP?
O Minimal Lower Layer Protocol: uma forma simples de enquadrar mensagens v2 sobre uma ligação TCP, com caracteres de início e fim à volta de cada mensagem e um reconhecimento (ACK) de volta. O FHIR utiliza HTTPS em vez disso.

### Posso converter mensagens HL7 v2 para FHIR automaticamente?
Na maioria dos casos. O guia de implementação v2-para-FHIR da HL7 fornece mapeamentos padrão, e os motores de integração implementam-nos. Espere trabalho manual para códigos locais, segmentos Z, fusos horários e como cada remetente utiliza campos opcionais.

### O Anpheros aceita HL7 v2?
Sim, para resultados de laboratório: mensagens ORU^R01 publicadas via HTTPS para o conector de laboratório tornam-se Observações FHIR. Outros tipos de mensagens v2 e ligações MLLP não são suportados.

## Relacionado

- [Mapeamento HL7 v2 para FHIR](https://developers.anpheros.com/pt/guides/hl7-v2-to-fhir-mapping): mapeamento de segmentos e campos, e um conversor
- [API de resultados de laboratório: HL7 v2, FHIR e LOINC](https://developers.anpheros.com/pt/guides/lab-results-api)
- [Como importar resultados de laboratório para um registo FHIR](https://developers.anpheros.com/pt/guides/import-lab-results-fhir)
- [Interoperabilidade de dados de saúde](https://developers.anpheros.com/pt/guides/interoperability)
- [DICOM vs FHIR: dados de imagem e dados clínicos](https://developers.anpheros.com/pt/guides/dicom-vs-fhir)
- [Plataforma FHIR](https://developers.anpheros.com/pt/guides/fhir)