FHIR ImagingStudy vs DICOMweb: o que contém o quê

Resposta curta: ImagingStudy é um recurso FHIR que diz este paciente fez uma TAC nesta data, com estas séries e estes UIDs de instância, e as imagens estão ali. DICOMweb é o ali: a interface REST do arquivo que contém os píxeis. O FHIR transporta a descrição e o relatório; o DICOM transporta as imagens. Um ImagingStudy referencia um recurso Endpoint cujo connectionType é dicom-wado-rs, e um visualizador combina os dois.

O que o ImagingStudy contém

O recurso FHIR ImagingStudy contém os metadados de um estudo de imagem: o DICOM Study Instance UID como identificador, um estado, o Paciente sujeito, o encontro, a hora de início e o ServiceRequest de pedido, códigos de modalidade do vocabulário DICOM DCM, contagens de séries e instâncias, o Endpoint onde as imagens residem e cada série com as suas instâncias e UIDs. Não contém píxeis.

identifier: o UID da Estudo DICOM, como urn:oid:1.2.840… com o sistema urn:dicom:uid;
status: registered, available, cancelled, entered-in-error, unknown;
subject: o Paciente; encounter, started, referrer, basedOn (o ServiceRequest que o encomendou);
modality: códigos do próprio vocabulário do DICOM (CT, MR, US, CR, DX…), sistema http://dicom.nema.org/resources/ontology/DCM;
numberOfSeries, numberOfInstances;
endpoint: onde buscar as imagens;
series[]: cada um com o seu UID da Série, modalidade, local do corpo, instance[] com UID da Instância SOP e UID da Classe SOP.

O que não contém: dados de píxeis, definições de janela, o cabeçalho DICOM completo, ou o texto do relatório. O relatório é um DiagnosticReport com imagingStudy a apontar de volta.

Um exemplo válido de FHIR R4

Um exemplo válido de FHIR R4 ImagingStudy contém o Study Instance UID como identificador com o sistema urn:dicom:uid, estado disponível, uma modalidade CT do sistema de código DICOM DCM, o paciente, a hora de início, contagens de séries e instâncias, uma referência a um Endpoint de connectionType dicom-wado-rs e entradas de série com os seus UIDs, local do corpo e SOP Class UID.

{
  "resourceType": "ImagingStudy",
  "id": "ct-chest-2026-03",
  "identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:1.2.840.113619.2.55.3.2831164356.781.1710415000.1"}],
  "status": "available",
  "modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"}],
  "subject": {"reference": "Patient/example"},
  "started": "2026-03-14T09:12:00+01:00",
  "numberOfSeries": 2,
  "numberOfInstances": 412,
  "endpoint": [{"reference": "Endpoint/pacs-dicomweb"}],
  "series": [{
    "uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.2",
    "number": 1,
    "modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"},
    "bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
    "numberOfInstances": 410,
    "instance": [{
      "uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.3",
      "sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.2"},
      "number": 1
    }]
  }]
}

O UID da Classe SOP 1.2.840.10008.5.1.4.1.1.2 é CT Image Storage. O Endpoint parece com isto:

{
  "resourceType": "Endpoint",
  "id": "pacs-dicomweb",
  "status": "active",
  "connectionType": {"system": "http://terminology.hl7.org/CodeSystem/endpoint-connection-type", "code": "dicom-wado-rs"},
  "payloadType": [{"text": "DICOM WADO-RS"}],
  "address": "https://pacs.example-hospital.org/dicomweb"
}

Um visualizador constrói o URL de recuperação a partir dos dois: {Endpoint.address}/studies/{StudyInstanceUID}, depois chama WADO-RS para metadados e frames.

Quem cria recursos ImagingStudy

Os recursos ImagingStudy são geralmente criados por uma fachada FHIR em frente ao PACS ou VNA, ou por um motor de integração, quando um estudo está completo, muitas vezes acionado pela mensagem HL7 v2 ORU ou DICOM MPPS. Alguns arquivos geram-nos na hora a partir de uma consulta QIDO-RS. O próprio scanner não cria recursos ImagingStudy.

Normalmente não é o scanner. Uma fachada FHIR à frente do PACS ou VNA, ou um motor de integração, cria o ImagingStudy quando o estudo está completo (muitas vezes acionado pela mensagem HL7 v2 ORU ou DICOM MPPS) e mantém numberOfInstances sincronizado. Alguns arquivos geram ImagingStudy dinamicamente a partir de uma consulta QIDO-RS. Se o seu projeto os escreve manualmente, os UIDs devem corresponder exatamente ao arquivo, caractere por caractere, ou o visualizador mostrará um estudo vazio.

Erros que quebram visualizadores

Os erros que quebram os visualizadores ao ler um FHIR ImagingStudy são: colocar o Study UID em id em vez de identifier, usar um código de modalidade não-DICOM, apontar um Endpoint com o connectionType errado para um servidor DICOMweb, deixar as contagens de séries e instâncias desatualizadas após alterações nas imagens e esperar dados de píxeis num FHIR Binary em vez de num arquivo DICOM.

Colocar o UID do Estudo em id em vez de identifier; os IDs FHIR são atribuídos pelo servidor e podem não ser OIDs.
Uma modalidade do SNOMED ou uma lista local em vez do sistema de código DICOM DCM.
Um Endpoint com connectionType hl7-fhir-rest a apontar para um servidor DICOMweb, ou o inverso.
Contar séries e instâncias uma vez e nunca atualizar quando imagens são adicionadas ou removidas.
Esperar os dados de píxeis no FHIR Binary. A própria especificação FHIR diz que as imagens pertencem ao DICOM, não ao Binary.

Num registo Anpheros

A Plataforma Anpheros não aloja dados ImagingStudy ou DICOM. Os achados radiológicos chegam como DiagnosticReport ou DocumentReference (o relatório, com os seus códigos e texto); onde o hospital expõe um link para um visualizador, o DocumentReference pode transportá-lo como um URL de anexo. As imagens permanecem no arquivo do hospital sob as suas regras de acesso.

Páginas relacionadas

Fontes

Perguntas frequentes

Um servidor FHIR pode armazenar as próprias imagens?

Tecnicamente, um Binary pode conter quaisquer bytes, mas a especificação FHIR recomenda contra isso para imagens e nenhum visualizador funciona dessa forma. As imagens ficam num arquivo DICOM; o FHIR aponta para ele.

O que mudou no FHIR R5 para ImagingStudy?

O R5 mantém a mesma forma, arruma a nomenclatura (por exemplo, procedure substitui procedureReference e procedureCode) e alinha o tratamento do local do corpo. O R4 continua a ser a versão que a maioria dos arquivos e perfis nacionais utilizam.

Como é que o relatório se liga às imagens?

DiagnosticReport.imagingStudy referencia o ImagingStudy; DiagnosticReport.media pode conter imagens chave como recursos Media. O ImagingStudy referencia o Endpoint para o estudo completo.

Preciso de ImagingStudy se já tenho DICOMweb?

Apenas se outros consumidores FHIR precisarem de saber que o estudo existe, por exemplo, uma aplicação para o paciente, um plano de cuidados ou uma exportação de pesquisa. Um visualizador de radiologia sozinho pode funcionar com QIDO-RS e WADO-RS.

Anpheros Daily

Experimente no Anpheros Daily

Guarde os seus relatórios de exames e análises num só local no Anpheros Daily, prontos para mostrar na sua próxima consulta.

Como funciona na app →

iPhone e Mac Android Abra no seu navegador →

Este guia é meramente informativo e não substitui aconselhamento médico. Para decisões sobre a sua saúde, fale com o seu médico. Em uma emergência, ligue para o número de emergência local (112 na Europa).

Escrito por

A equipa Anpheros

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 →