Compreender o esquema DICOM do BigQuery

Esta página explica o esquema da tabela do BigQuery criada quando exporta metadados DICOM para o BigQuery.

Terminologia

Para compreender o esquema e os respetivos componentes, familiarize-se com a terminologia DICOM. Em particular, esta página usa vários termos encontrados em 3.10 DICOM Data Structures and Encoding Definitions.

Vista geral

A Cloud Healthcare API gera automaticamente o esquema do BigQuery com base nos dados que está a exportar e no dicionário DICOM. O esquema contém apenas colunas para elementos de dados DICOM que existem nos metadados. A única exceção é o nome da pessoa VR.

Ao exportar metadados DICOM, a Cloud Healthcare API tenta exportar todos os elementos de dados nos metadados. Para obter informações sobre o que acontece se surgir um problema, consulte o artigo Tipos em conflito e com incompatibilidade.

Elementos de dados padrão e privados

O DICOM fornece elementos de dados padrão que estão em conformidade com uma especificação predefinida. Para ver uma lista destes elementos de dados, consulte o Registo de elementos de dados DICOM.

Nos casos em que tem de comunicar dados que não estão em conformidade com os elementos padrão, pode usar elementos de dados privados.

Elementos de dados padrão

Os seguintes comportamentos aplicam-se aos elementos de dados padrão. Para o comportamento dos elementos de dados privados, consulte Elementos de dados privados.

Nomes das colunas

As colunas no esquema do BigQuery gerado são denominadas de acordo com a palavra-chave do elemento de dados. Por exemplo, se os metadados DICOM contiverem um elemento de dados cuja palavra-chave seja InstanceCreationDate, o esquema gerado tem uma coluna correspondente denominada InstanceCreationDate.

Comportamento do elemento de dados DICOM padrão

A tabela seguinte mostra uma lista de representações de valores (VRs) e as respetivas abreviaturas. Para qualquer elemento de dados exportado para o BigQuery que contenha um destes VRs, o elemento de dados usa o tipo de dados do BigQuery encontrado em "Tipo de dados":

RV Tipo de dados
  • Entidade de aplicação (AE)
  • Age String (AS)
  • String de código (CS)
  • String longa (LO)
  • Texto longo (LT)
  • String curta (SH)
  • Texto curto (ST)
  • Carateres ilimitados (UC)
  • Identificador único (UI/UID)
  • Identificador de recursos universal (UR) ou localizador de recursos universal (URI/URL)
  • Mensagens de texto ilimitadas (UT)
String
Data (DA) Data
Time (TM) Hora
Data/hora (DT) Data/hora
  • String decimal (DS)
  • String de número inteiro (IS)
String
Nome da pessoa (PN) Struct (Record)
  • Floating Point Single (FL)
  • Vírgula flutuante dupla (FD)
Vírgula flutuante
  • Etiqueta de atributo (AT)
  • Signed Long (SL)
  • Vídeo curto com legendas (SS)
  • Unsigned Long (UL)
  • Vídeo curto sem assinatura (EUA)
Inteiro
Sequência de itens (SQ) Struct (Record)

Modos anuláveis e repetidos

Consoante o valor de multiplicidade (VM) de um elemento de dados, a respetiva coluna do BigQuery tem um de dois modos: NULLABLE ou REPEATED.

Se um elemento de dados tiver um valor de VM de 1, o que indica que o elemento de dados é único, o elemento de dados usa o modo NULLABLE. Para qualquer outro valor de VM, o elemento de dados usa o modo REPEATED.

Por exemplo, conforme mostrado no Registo de elementos de dados DICOM, a palavra-chave SOPInstanceUID tem um valor VM de 1. Como resultado, quando é exportado para o BigQuery, o respetivo modo é NULLABLE, e a respetiva representação na tabela tem o seguinte aspeto (quando representado como JSON):

"SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000",

Por outro lado, a palavra-chave ImageType tem um valor de VM de 2-n. Como resultado, quando é exportado para o BigQuery, o respetivo modo é REPEATED e a respetiva representação na tabela tem o seguinte aspeto (quando representado como JSON):

"ImageType": [
  "ORIGINAL",
  "PRIMARY",
  "OTHER",
  "..."
],

Registos de visualização excluídos

Os dados binários e de formato longo não são exportados para a tabela do BigQuery gerada, pelo que os elementos de dados que contêm os seguintes VRs não são exportados. Em alternativa, os seguintes VRs são incluídos numa coluna separada (denominada DroppedTags.TagName) na tabela de destino do BigQuery.

  • Outro duplo (OD)
  • Outro flutuador (OF)
  • Outro longo (OL)
  • Outro byte (OB)
  • Outra palavra (OW)
  • Desconhecido (UN)
  • Etiquetas de sequência (SQ) que contêm mais de aproximadamente 1 MiB de dados
  • Attribute (AT), Floating Point Double (FD), Floating Point Single (FL), Unsigned Long (UL) ou Unsigned Short (US), se a Value Multiplicity (VM) for superior a 512.
    • Por motivos de compatibilidade com versões anteriores, as etiquetas de instâncias já carregadas na Cloud Healthcare API podem ser incluídas na coluna DroppedTags.TagName se a multiplicidade de valores for superior a 64.

Person Name VR

Cada coluna no esquema do BigQuery com um VR de nome de pessoa (PN) contém sempre três subcolunas, independentemente de as subcolunas conterem dados. As três subcolunas são:

  • Alfabético
  • Ideográfico
  • Fonética

Cada uma das três subcolunas tem as suas próprias cinco subcolunas:

  • FamilyName
  • GivenName
  • MiddleName
  • NamePrefix
  • NameSuffix

Por exemplo, considere a etiqueta pública "OperatorsName (0008,1070)", que tem um VR de nome de pessoa (PN). Suponhamos que o valor de OperatorsName é "Darcy Smith". O esquema vai conter uma coluna OperatorsName com as subcolunas indicadas anteriormente, mas apenas Alphabetic.FamilyName (Smith) e Alphabetic.GivenName (Darcy) vão conter valores.

Elementos de dados privados

Algumas implementações clínicas podem exigir que armazene dados personalizados que não se enquadram na estrutura dos elementos de dados públicos. Em alternativa, pode usar elementos de dados privados.

Os elementos de dados privados com um VR de SQ (Sequence of Items) têm o mesmo comportamento que os elementos de dados padrão. Os elementos de dados privados com um VR de SQ são denominados sequências de dados privados.

Os elementos de dados privados que não têm um VR de SQ estão aninhados numa coluna denominada OtherElements e são convertidos em strings. Estes elementos de dados privados são denominados dados privados não sequenciais. Para consultar elementos de dados privados que não sejam de sequência, a consulta tem de pesquisar na coluna OtherElements do elemento.

A coluna OtherElements contém duas subcolunas: "Dados" e "Etiqueta". A coluna de dados é a representação de string do valor do elemento de dados privado. É sempre do tipo REPEATED. A coluna Etiqueta usa o formato "Tag_HEX", em que HEX é uma string hexadecimal do número da etiqueta.

Colunas LastUpdated e Type

As colunas LastUpdated e Type são adicionadas à tabela do BigQuery criada quando exporta metadados DICOM. Estas colunas não são elementos de dados padrão nem privados e não correspondem ao registo de elementos de dados DICOM.

O comportamento destas colunas é o seguinte:

  • A coluna LastUpdated contém um valor de data/hora que mostra quando a instância DICOM foi inserida ou eliminada da loja DICOM.
  • A coluna Type contém uma string que mostra o tipo de operação que ocorreu. Os valores possíveis são CREATE ou DELETE.

Tipos em conflito e com incompatibilidade

Se ocorrer um conflito de tipo, como quando uma etiqueta pública é usada com um tipo incorreto, a etiqueta pública é tratada como se fosse uma etiqueta privada. O valor do elemento de dados está aninhado numa coluna denominada OtherElements e o valor é convertido numa string.

Por exemplo, suponhamos que os metadados DICOM contêm uma etiqueta com:

  • Um número de etiqueta "(4010,1017)"
  • Um RV de SL (Signed Long)
  • Um valor de 32

(4010,1017) é o mesmo número de etiqueta que "Massa", que é um nome de etiqueta público na especificação DICOM que tem um VR de FL. A operação de exportação espera que um elemento de dados com o número de etiqueta "(4010,1017)" seja o nome da etiqueta pública "Massa" com um VR de FL. Por conseguinte, a operação de exportação espera converter o valor do elemento de dados num número de vírgula flutuante (como mostrado na tabela em Comportamento padrão do elemento de dados DICOM

Ocorre um conflito de tipos porque todas as etiquetas com um VR de SL usam o tipo de dados integer. Por conseguinte, a etiqueta é convertida numa etiqueta privada e adicionada à coluna OtherElements.

Se for usado um nome de etiqueta pública não sequencial para dados de sequência, ocorre uma incompatibilidade de tipo. Como resultado, a sequência é tratada como se fosse um elemento de dados privado. Em vez de usar o nome da etiqueta pública como o nome da coluna no esquema do BigQuery, é usado o número hexadecimal do nome da etiqueta pública. O número hexadecimal é do tipo string.

Exemplos: consultar elementos de dados públicos e privados

Considere o seguinte fragmento de um esquema representado como JSON. O esquema foi criado após a exportação de dados DICOM para o BigQuery.

[
  ...
  {
    "name": "SOPInstanceUID",
    "type": "STRING"
  },
  {
    "fields": [
      {
        "fields": [
          {
            "mode": "REQUIRED",
            "name": "Tag",
            "type": "STRING"
          },
          {
            "mode": "REPEATED",
            "name": "Data",
            "type": "STRING"
          }
        ],
        "mode": "REPEATED",
        "name": "OtherElements",
        "type": "RECORD"
      }
    ],
    "mode": "REPEATED",
    "name": "Tag_12345678",
    "type": "RECORD"
  }
  ...
]

O exemplo seguinte mostra como consultar o elemento de dados públicos SOPInstanceUID. Para aceder ao valor da coluna, execute a seguinte consulta:

#standardSQL
SELECT
  SOPInstanceUID
FROM
  `PROJECT_ID.DATASET_ID.TABLE_ID`

A execução da consulta devolve um resultado semelhante ao seguinte:

[
  ...
  {
    "SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000"
  },
  ...
]

O exemplo seguinte mostra como consultar dados privados não sequenciais. Execute a seguinte consulta na coluna OtherElements, que se encontra na coluna Tag_12345678. Tenha em atenção a utilização do operador UNNEST, que é obrigatório porque está a consultar um RECORD.

#standardSQL
SELECT
  Tag_12345678.OtherElements AS OtherElements
FROM
  `PROJECT_ID.DATASET_ID.TABLE_ID`,
  UNNEST(Tag_12345678) AS Tag_12345678

A execução da consulta devolve um resultado semelhante ao seguinte, consoante a quantidade e o tipo de dados na coluna Tag_12345678.OtherElements:

[
  {
    "OtherElements": [
      {
        "Tag": "Tag_12345678",
        "Data": [
          "DATA"
        ]
      }
    ]
  },
  {
    "OtherElements": [
      {
        "Tag": "Tag_12345678",
        "Data": [
          "DATA"
        ]
      }
    ]
  },
  {
    "OtherElements": [
      {
        "Tag": "Tag_12345678",
        "Data": [
          "DATA"
        ]
      }
    ]
  }
]

Esquema JSON

Pode exportar metadados de instâncias DICOM para uma tabela do BigQuery com um esquema mais simples, onde os metadados de instâncias completos são armazenados como uma única coluna JSON. Isto pode ser útil quando prefere trabalhar com a estrutura JSON não processada dos metadados DICOM no BigQuery. Também é útil quando o número de etiquetas únicas em todas as instâncias DICOM excede o número máximo de colunas permitidas numa tabela do BigQuery.

Para ativar o esquema JSON, defina o campo schema_json no BigQueryDestination. Para mais detalhes sobre a configuração do esquema, consulte BigQueryDestination.

Quando o esquema JSON está ativado, a tabela do BigQuery tem as seguintes colunas:

Nome do campo Tipo Descrição
StudyInstanceUID STRING Etiqueta DICOM (0020,000D).
SeriesInstanceUID STRING Etiqueta DICOM (0020,000E).
SOPInstanceUID STRING Etiqueta DICOM (0008,0018).
SourceDicomStore STRING O nome do arquivo DICOM de origem. Este campo só é incluído se a opção includeSourceStore estiver definida como verdadeira na configuração de exportação.
Type STRING Indica o tipo de operação que acionou a exportação (por exemplo, CREATE, DELETE).
LastUpdated TIMESTAMP Data/hora da última atualização da instância no arquivo DICOM.
Metadata JSON Todas as etiquetas DICOM da instância, armazenadas num único objeto JSON.
DroppedTags REPEATED STRING Lista de etiquetas que foram ignoradas durante a conversão, normalmente etiquetas binárias ou muito grandes.
StorageClass STRING A classe de armazenamento da instância (por exemplo, STANDARD ou NEARLINE).
BlobStorageSize INTEGER Tamanho do armazenamento de blobs em bytes.
StructuredStorageSize INTEGER Tamanho do armazenamento estruturado em bytes.

Exemplo: consultar a coluna JSON de metadados

Segue-se um exemplo de como consultar uma etiqueta DICOM específica da coluna Metadata de acordo com o suporte de dados JSON do BigQuery. Esta consulta seleciona as etiquetas PatientID e PatientAge:

#standardSQL
SELECT
  Metadata.PatientID AS patient_id,
  Metadata.PatientAge AS patient_age
FROM
  `PROJECT_ID.DATASET_ID.TABLE_ID`;

A execução da consulta devolve um resultado semelhante ao seguinte:

/*-------------+---------------*
| patient_id   | patient_age   |
+--------------+---------------+
| "John-Doe"   | "042Y"        |
*--------------+---------------*/

Pode adaptar a consulta para extrair outras etiquetas DICOM da coluna JSON Metadata, conforme necessário.

O que se segue?

Saiba mais sobre as operações do SQL padrão do BigQuery e veja exemplos.