Resposta curta: os dados de saúde circulam através de quatro camadas de normas. As normas de intercâmbio transportam os dados entre sistemas: mensagens HL7 v2, documentos CDA, recursos FHIR e DICOM para imagens. As normas de modelagem e armazenamento definem como um registo é estruturado dentro de um sistema: openEHR para registos clínicos, OMOP para bases de dados de investigação. As terminologias atribuem a cada conceito um código que ambas as partes compreendem: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. As normas de identidade e segurança decidem quem pode ler o quê: OAuth 2.0 e SMART on FHIR, mais perfis IHE que combinam tudo o anterior em receitas testadas. Ninguém usa apenas uma; um hospital executa tipicamente todas as quatro camadas em simultâneo.
O mapa
Os padrões de interoperabilidade na saúde formam quatro camadas. Os padrões de troca (HL7 v2, CDA, FHIR, DICOM e DICOMweb) movem dados entre sistemas, e os perfis IHE combinam-nos em "receitas" testadas. O openEHR estrutura o registo armazenado e o OMOP estrutura as bases de dados de investigação. Terminologias como SNOMED CT e LOINC, e padrões de identidade como SMART on FHIR, são usadas em todos eles.
| Camada | Norma | O que é | Onde a encontra em 2026 |
|---|---|---|---|
| Intercâmbio | HL7 v2 | Mensagens delimitadas por pipe (ADT, ORU, ORM, SIU) sobre MLLP | Dentro de hospitais: admissões, resultados de laboratório, pedidos, agendamento. Ainda a interface mais comum |
| Intercâmbio | CDA / C-CDA | Documentos clínicos XML com uma parte legível por humanos e entradas codificadas | Resumos de alta, cartas de referência, o C-CDA dos EUA, resumos transfronteiriços no MyHealth@EU |
| Intercâmbio | FHIR (R4, R4B, R5) | Recursos web (Patient, Observation, Condition…) sobre REST e JSON | Aplicações para pacientes, APIs nacionais, APIs de EHR, US Core, o formato de intercâmbio EHDS |
| Intercâmbio | DICOM e DICOMweb | Objetos de imagem com metadados incorporados; DICOMweb é a sua interface REST | Todos os scanners, PACS e visualizadores de radiologia; visualizadores web usam DICOMweb |
| Receitas | Perfis IHE | Combinações testadas do acima para um caso de uso (XDS, PIX/PDQ, XCA, SWF) | Partilha de documentos entre hospitais e regiões, identidade do paciente, fluxo de trabalho de radiologia |
| Armazenamento | openEHR | Modelo de dados clínicos baseado em arquétipos para o próprio registo | Plataformas de EHR hospitalares e nacionais em partes da Europa, Escandinávia, Brasil |
| Investigação | OMOP CDM | Um modelo relacional comum para investigação observacional | Redes de investigação, evidência do mundo real, uso secundário do EHDS |
| Terminologia | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | Códigos para achados, testes, diagnósticos, medicamentos, unidades | Dentro de cada uma das normas acima |
| Identidade | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | Quem é o utilizador e o que a aplicação pode aceder | Todas as aplicações voltadas para o paciente e todas as plataformas de aplicações de EHR |
Como as camadas se encaixam
As camadas dos padrões de interoperabilidade na saúde encaixam-se ao realizarem cada uma uma tarefa no mesmo fluxo de trabalho: uma mensagem HL7 v2 transporta um pedido de análise, LOINC e UCUM codificam o resultado, uma plataforma openEHR armazena-o, uma API FHIR disponibiliza-o a uma aplicação do paciente após um login SMART on FHIR, e um documento CDA partilha-o com outro hospital.
Um exame de sangue mostra as quatro camadas numa tarde. O pedido sai da enfermaria como uma mensagem HL7 v2 ORM (intercâmbio). O resultado do analisador regressa como um HL7 v2 ORU, com o teste codificado em LOINC e a unidade em UCUM (terminologia). O hospital armazena-o na sua própria base de dados, talvez uma plataforma openEHR (armazenamento). A aplicação do paciente lê-o através de uma API FHIR como uma Observation, depois de o paciente ter iniciado sessão com SMART on FHIR (identidade). Se o hospital partilhar o relatório completo com outro hospital, pode fazê-lo como um documento CDA através de um registo IHE XDS. Se o resultado se juntar mais tarde a uma coorte de investigação, é convertido em OMOP.
As normas não são concorrentes. Cada uma foi construída para uma tarefa diferente, e substituir uma por outra geralmente significa reconstruir algo que já funciona.
Qual precisa?
O padrão de interoperabilidade na saúde de que precisa depende da tarefa: FHIR R4 com SMART on FHIR para aplicações de pacientes ou clínicos, HL7 v2 para ligação a sistemas hospitalares existentes, DICOM e DICOMweb para imagens, documentos CDA ou FHIR para documentos completos, openEHR para armazenamento de registos a longo prazo, OMOP para investigação, e perfis IHE quando dois sistemas têm de se comportar de forma idêntica.
- Está a construir uma aplicação para pacientes ou clínicos: FHIR R4, com os perfis do seu mercado (guias de implementação), SMART on FHIR para login.
- Está a ligar-se aos sistemas existentes de um hospital: espere HL7 v2 primeiro; FHIR onde o fornecedor o oferece. Veja Mensagens HL7 v2 explicadas.
- Lida com imagens: DICOM para armazenamento e transferência, DICOMweb para qualquer coisa num navegador, FHIR ImagingStudy apenas para os metadados. Veja DICOMweb explicado e ImagingStudy vs DICOMweb.
- Troca documentos completos (resumos, cartas): CDA onde é obrigatório, documentos FHIR (um Bundle do tipo
document) onde pode escolher. Veja CDA e C-CDA explicados. - Projeta como um registo é armazenado durante décadas: openEHR, com FHIR como camada de intercâmbio. Veja openEHR vs FHIR.
- Executa investigação sobre muitos registos: OMOP, com FHIR como fonte. Veja Uso secundário de dados de saúde.
- Precisa que dois sistemas se comportem da mesma maneira: escolha o perfil IHE para o seu caso de uso e teste contra ele.
Onde a Anpheros se encaixa
A Anpheros Platform situa-se na camada de troca do mapa de padrões como um servidor FHIR R4 com acesso OAuth 2.0 e webhooks para notificações de alterações, recebendo resultados de análises através de um conector a partir de HL7 v2 ORU, CSV ou JSON. Não armazena imagens DICOM nem oferece um serviço CDS Hooks; estes permanecem nos sistemas hospitalares.
A Plataforma Anpheros é um servidor FHIR R4 com os recursos de que um registo centrado no paciente necessita (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance e outros), OAuth 2.0 para acesso e webhooks para notificações de alterações. Os resultados de laboratório chegam através do conector de laboratório a partir de HL7 v2 ORU, CSV ou JSON. Não armazena imagens DICOM e não oferece um serviço CDS Hooks; estes permanecem nos sistemas do hospital, e o registo aponta para eles.
Ordem de leitura
Uma boa ordem de leitura para os padrões de interoperabilidade na saúde começa com o que é FHIR e como difere de HL7 v2, depois o recurso FHIR Observation, as terminologias LOINC e SNOMED CT usadas nele, depois DICOMweb para imagens, CDA para documentos e, finalmente, openEHR comparado com FHIR sobre como os registos são armazenados.
Se é novo na área: O que é FHIR → HL7 vs FHIR → FHIR Observation → LOINC e SNOMED CT → DICOMweb → CDA → openEHR vs FHIR.
Páginas relacionadas
- HL7 vs FHIR
- Mensagens HL7 v2 explicadas
- CDA e C-CDA explicados
- DICOMweb explicado
- openEHR vs FHIR
- Guias de implementação FHIR
- FHIR R4 vs R5
- O que é um código LOINC?
- O que é SNOMED CT?
- DICOM vs FHIR para programadores
- Perfis e extensões FHIR explicados
- Servidores de terminologia FHIR explicados
- Mapa de regulamentação de dados de saúde
- Registos eletrónicos de saúde nacionais na Europa e nos EUA
- Integração de sistemas hospitalares explicada
- IA em dados médicos
- Uso secundário de dados de saúde
- Segurança e identidade em aplicações de saúde
Fontes
- HL7 International: normas
- Especificação HL7 FHIR R4
- Norma DICOM, edição atual
- Estruturas técnicas IHE
- Especificações openEHR
- Modelo de Dados Comum OMOP OHDSI
- SMART App Launch
Perguntas frequentes
O FHIR está a substituir todas as outras normas?
Não. O FHIR está a substituir APIs personalizadas e, lentamente, alguma troca de documentos CDA. O HL7 v2 continua a ser o cavalo de batalha dentro dos hospitais, o DICOM continua a ser a única norma para imagens, e o openEHR e o OMOP respondem a questões (armazenamento, investigação) para as quais o FHIR não foi concebido.
Qual é a diferença entre uma norma e um perfil IHE?
Uma norma como FHIR ou DICOM define blocos de construção. Um perfil IHE seleciona blocos específicos, fixa as suas opções e diz exatamente como os sistemas devem utilizá-los para uma tarefa, de modo que dois fornecedores que ambos passem nos testes IHE possam trabalhar em conjunto sem um projeto.
Que norma utilizam os sistemas nacionais de saúde?
A maioria dos sistemas europeus começou com documentos CDA e HL7 v2, e estão a adicionar APIs FHIR; o formato de intercâmbio EHDS é construído sobre FHIR e o IPS. Os EUA exigem FHIR US Core para acesso do paciente e C-CDA para troca de documentos.
Onde se encaixam SNOMED CT e LOINC?
Não são normas de intercâmbio; são vocabulários utilizados em todas elas. Um código LOINC identifica o teste num segmento HL7 v2 OBX, uma entrada CDA e uma Observation FHIR, respetivamente.
Experimente grátis no sandbox
Sua primeira chamada FHIR em 5 minutos. Uma API HL7 FHIR R4 com o consentimento do paciente integrado: experimente na sandbox e depois conecte a sua própria app ou sistema clínico.
Grátis · 30 pacientes sintéticos · sem cartão
A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.
Sobre a Anpheros →