Noções básicas sobre o esquema DICOM do BigQuery

Nesta página, explicamos o esquema da tabela do BigQuery que é criada ao exportar metadados do DICOM para o BigQuery.

Terminologia

Para entender o esquema e os componentes dele, familiarize-se com a terminologia DICOM. Especificamente, esta página usa vários termos encontrados em 3.10 Estruturas de dados DICOM e definições de codificação.

Visão geral

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

Ao exportar metadados DICOM, a API Cloud Healthcare tenta exportar todos os elementos de dados nos metadados. Para informações sobre o que acontece se ocorrer um problema, consulte Tipos conflitantes e incompatíveis.

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 desses elementos de dados, consulte Registro de elementos de dados DICOM.

Nos casos em que você precisa comunicar dados que não estão em conformidade com os elementos padrão, é possível usar elementos de dados particulares.

Elementos de dados padrão

Os comportamentos a seguir se aplicam a elementos de dados padrão. Para saber mais sobre o comportamento de elementos de dados particulares, consulte Elementos de dados particulares.

Nomes de coluna

As colunas no esquema do BigQuery gerado são nomeadas de acordo com a palavra-chave do elemento de dados. Por exemplo, se os metadados DICOM tiverem um elemento de dados com a palavra-chave InstanceCreationDate, o esquema gerado terá uma coluna correspondente chamada InstanceCreationDate.

Comportamento padrão do elemento de dados DICOM

A tabela a seguir mostra uma lista de representações de valor (VRs, na sigla em inglês) e suas abreviações. Para qualquer elemento de dados exportado para o BigQuery que contenha uma dessas VRs, o elemento de dados usa o tipo de dados do BigQuery encontrado em "Tipo de dados":

VR Tipo de dado
  • Entidade do aplicativo (AE)
  • String de idade (AS)
  • String de código (CS)
  • String longa (LO)
  • Texto longo (LT)
  • String curta (SH)
  • Texto curto (ST)
  • Caracteres ilimitados (UC)
  • Identificador exclusivo (UI/UID)
  • Identificador de recursos universal (UR) ou Localizador de recursos universal (URI/URL)
  • Texto ilimitado (UT)
 String
Data (DA) Data
Horário (TM) Hora
Data/Hora (DT) Carimbo de data/hora
  • String decimal (DS)
  • String de número inteiro (IS)
 String
Nome da pessoa (PN) Struct (Record)
  • Ponto flutuante único (FL)
  • Ponto flutuante duplo (FD)
 Ponto flutuante
  • Tag de atributo (AT)
  • Longa com sinal (SL)
  • Curta sem sinal (SS)
  • Não assinada (UL)
  • Longa sem sinal (US)
 Número inteiro
Sequência de itens (SQ) Struct (Registro)

Modos nulos e repetidos

Dependendo do valor de multiplicação de valores (VM, na sigla em inglês) de um elemento de dados, a coluna do BigQuery tem um dos dois modos: NULLABLE ou REPEATED.

Se um elemento de dados tiver um valor de VM de 1, que indica que o elemento de dados é exclusivo, 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 Registro de elementos de dados DICOM, a palavra-chave SOPInstanceUID tem um valor de VM de 1. Como resultado, quando ele é exportado para o BigQuery, o modo é NULLABLE e a representação na tabela é semelhante a esta (quando representada 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 ele é exportado para o BigQuery, o modo é REPEATED e a representação na tabela é semelhante a esta (quando representada como JSON):

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

VRs excluídas

Os dados binários e longos não são exportados para a tabela gerada do BigQuery. Portanto, os elementos de dados que contêm as seguintes RVs não são exportados. Em vez disso, as RVs a seguir são incluídas em uma coluna separada (chamada DroppedTags.TagName) na tabela de destino do BigQuery.

  • Outro (DO)
  • Outro flutuante (OF)
  • Outro longo (OL)
  • Outro byte (OB)
  • Outra palavra (OW)
  • Desconhecido (UN)
  • Tags de sequência (SQ) que contêm mais de aproximadamente 1 MiB de dados
  • Atributo (AT), ponto flutuante duplo (FD), ponto flutuante único (FL), longo sem sinal (UL) ou short sem sinal (US), se a multiplicação de valores (VM) for maior que 512.
    • Por motivos de legados, as tags de instâncias já ingeridas na API Cloud Healthcare podem ser incluídas na coluna DroppedTags.TagName se a multiplicidade de valores for maior que 64.

VRs do nome da pessoa

Cada coluna do esquema do BigQuery com um VR do Nome da pessoa (PN, na sigla em inglês) sempre contém três subcolunas, independentemente de as subdados conterem dados. As três subcolunas são:

  • Alfabética
  • Ideográfica
  • Fonética

Cada uma das três sub-colunas tem suas próprias cinco sub-colunas:

  • FamilyName
  • GivenName
  • MiddleName
  • NamePrefix
  • NameSuffix

Por exemplo, considere a tag pública "OperatorsName (0008,1070)", que tem uma VR do nome da pessoa (PN). Suponha que o valor de OperatorsName seja "Darcy Smith". O esquema conterá uma coluna OperatorsName cque contém as sub-colunas listadas anteriormente, mas apenas Alphabetic.FamilyName (Smith) e Alphabetic.GivenName (Darcy) terão valores.

Elementos de dados privados

Algumas implementações estratégicas podem exigir o armazenamento de dados personalizados que não se encaixam na estrutura de elementos de dados públicos. Como alternativa, você pode usar elementos de dados particulares.

Os elementos de dados particulares com uma VR de SQ (sequência de itens) têm o mesmo comportamento dos elementos de dados padrão. Elementos de dados particulares com uma VR de SQ são chamados de sequências de dados particulares.

Os elementos de dados particulares que não têm uma VR de SQ são aninhados em uma coluna chamada OtherElements e convertidos em strings. Esses elementos de dados particulares são chamados de dados privados sem sequência. Para consultar elementos de dados privados não sequenciais, a consulta precisa pesquisar na coluna OtherElements do elemento.

A coluna OtherElements contém duas subcolunas, "Data" e "Tag". A coluna "Data" é a representação de string do valor do elemento de dados particular. É sempre do tipo REPEATED. A coluna Tag usa o formato "Tag_ HEX", em que HEX é uma string hexadecimal do número da tag.

Colunas LastUpdated e Type

As colunas LastUpdated e Type são adicionadas à tabela do BigQuery criada quando você exporta metadados DICOM. Essas colunas não são elementos de dados padrão ou particulares e não correspondem ao Registro de elementos de dados DICOM.

O comportamento dessas colunas é o seguinte:

  • A coluna LastUpdated contém um valor de carimbo de data/hora que mostra quando a instância DICOM foi inserida ou excluída da armazenagem de 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 conflitantes e incompatíveis

Se ocorrer um conflito de tipo, como quando uma tag pública é usada com um tipo incorreto, ela será tratada como se fosse uma tag particular. O valor do elemento de dados é aninhado em uma coluna chamada OtherElements, e o valor é convertido em uma string.

Por exemplo, digamos que os metadados DICOM contenham uma tag com:

  • Um número de tag "(4010.0,017)"
  • Uma VR de SL (longa com sinal)
  • Um valor de 32

(4010,1017) é o mesmo número de tag que "Mass", que é um nome de tag público na especificação DICOM que tem uma VR de FL. A operação de exportação espera que um elemento de dados com o número de tag "(4010.01017)" seja o nome da tag pública "Mass" com uma vr de FL. Portanto, a operação de exportação espera a conversão do valor do elemento de dados em um flutuante (conforme mostrado na tabela em Comportamento do elemento de dados DICOM padrão).

Um conflito de tipos ocorre porque todas as tags com uma VR de SL usam o tipo de dados inteiro. Portanto, a tag é convertida em uma tag privada e adicionada à coluna OtherElements.

Se um nome de tag pública sem sequência for usado para dados sequenciais, ocorrerá uma incompatibilidade de tipo. Como resultado, a sequência é tratada como se fosse um elemento de dados particular. Em vez de usar o nome da tag pública como o nome da coluna no esquema do BigQuery, o número de instâncias do nome da tag pública é usado. O número hexadecimal é do tipo string.

Exemplos: como consultar elementos de dados públicos e privados

Considere o snippet a seguir 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"
  }
  ...
]

A amostra a seguir mostra como consultar o elemento de dados públicos SOPInstanceUID. Para acessar o valor da coluna, execute a seguinte consulta:

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

A execução da consulta retorna uma saída semelhante a esta:

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

Veja na amostra a seguir como consultar dados particulares sem sequência. Execute a seguinte consulta na coluna OtherElements, que está dentro da coluna Tag_12345678. Observe o uso do operador UNNEST, que é obrigatório porque você está consultando 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 retorna uma saída semelhante à seguinte, dependendo da quantidade e do 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"
        ]
      }
    ]
  }
]

A seguir

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